Click on "Deploy 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., "@sprout-mcp recommend model for biography synthesis"
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.
Drop your Opus bill 80%. Model-tiered content pipeline for MCP — cheap models seed work, expensive models verify it.
Sprout routes tasks to the right model tier automatically. Haiku drafts, Sonnet fact-checks, Opus verifies. Every chunk tracks provenance, confidence, and cost.
uvx sprout-mcpOr add to Claude Code's MCP config (~/.claude/settings.json):
{
"mcpServers": {
"sprout": {
"command": "uvx",
"args": ["sprout-mcp"]
}
}
}Related MCP server: routewise
Haiku (seed) → Sonnet (watered) → Opus (sprouted)
Draft Fact-check Verify
$0.005/M $0.015/M $0.075/MSeed — Haiku drafts content cheaply (summarization, extraction, first passes)
Water — Sonnet reviews and fact-checks the seeds
Sprout — Opus deep-verifies only what passed Sonnet's review
Instead of running everything through Opus at $75/M output tokens, most work stays at Haiku's $5/M. Only the final verification — typically 10-20% of total work — touches Opus.
Tool | Description |
| Store content with provenance (model, task type, sources) |
| List chunks needing review, filtered by confidence/project |
| Promote (seed→watered→sprouted) or reject chunks |
| Get model recommendation for a task type |
| Dashboard of chunk counts, confidence levels, token usage |
| Export verified chunks as JSON |
| Generate structured review summary for batch verification |
| Schedule tasks to run at a specific time or delay |
| View pending scheduled tasks |
| Cancel a pending scheduled task |
| Add/update routing rules at runtime |
| Estimated spend per model with real pricing |
| Track failed attempts with backoff guidance |
Variable | Default | Description |
|
| SQLite database location |
| (none) | Path to JSON config file for custom routes and pricing |
|
| Max retry attempts before giving up |
|
| Exponential backoff base (seconds) |
Create a JSON file and point SPROUT_CONFIG at it:
{
"routes": {
"code_review": { "tier": "sonnet", "reason": "Code analysis needs reasoning" },
"translation": { "tier": "haiku", "reason": "Straightforward language task" }
},
"pricing": {
"custom-model": 10.00
}
}Task Type | Tier | Why |
| haiku | Factual summarization |
| haiku | Historical summarization |
| haiku | Content summarization |
| haiku | Structural verification |
| haiku | General summarization |
| haiku | Structured extraction |
| sonnet | Cross-reference claims |
| sonnet | Code analysis |
| opus | Deep factual verification |
| opus | Domain expertise required |
| opus | Deep reasoning required |
Unknown task types default to haiku — start cheap, escalate if needed.
You: Use recommend_model for "biography_synthesis"
Sprout: biography_synthesis → haiku-4.5 (Factual summarization)
You: Use submit_chunk to store the Haiku output
Sprout: Stored chunk abc12345 [seed] for person-001.biography
You: Use get_review_queue to see what needs fact-checking
Sprout: 1 chunk pending review
You: Use mark_reviewed to promote after Sonnet fact-checks it
Sprout: Chunk abc12345 → watered (verified by sonnet-4.6)
You: Use get_cost_report
Sprout: haiku-4.5: ~1,300 tokens (1 chunk) — $0.0065
Total: $0.0065git clone https://github.com/mepsopti/sprout-mcp.git
cd sprout-mcp
uv sync --extra dev
uv run pytestIf Sprout saves you money on your AI bill, consider buying me a coffee:
MIT
mcp-name: io.github.mepsopti/sprout-mcp
Cancel a pending scheduled task.
Args: task_id: Full or partial UUID of the task
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It does not disclose side effects (e.g., whether the task is deleted or archived), authorization needs, or reversibility of the cancellation.
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 very concise, front-loading the purpose in a single sentence. It avoids unnecessary words but could optionally include more context without being verbose.
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 simplicity (one required parameter, no nested objects, output schema exists), the description covers the essential aspect: what the tool does and the parameter format. Missing behavioral details slightly lower completeness.
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?
The description adds meaningful detail to the schema parameter 'task_id' by specifying it accepts 'Full or partial UUID', which goes beyond the schema's plain string type. With 0% schema description coverage, this is valuable.
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 'Cancel a pending scheduled task', using a specific verb ('Cancel') and resource ('scheduled task'). This distinguishes it from sibling tools like schedule_task (creates) and list_scheduled (lists).
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 implies usage for pending tasks only but does not explicitly state when to use this tool versus alternatives like list_scheduled or schedule_task. No exclusions or comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add or update a routing rule for a task type.
Args: task_type: Task type name (e.g. "code_review", "summarization") tier: Model tier — haiku, sonnet, or opus reason: Why this tier is appropriate
| Name | Required | Description | Default |
|---|---|---|---|
| task_type | Yes | ||
| tier | Yes | ||
| reason | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states 'Add or update' implying a mutation, but does not mention idempotency, permission requirements, side effects, or what happens on conflict. The output schema exists but is not referenced.
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 extremely concise: a single sentence preamble followed by a focused bullet list for each parameter. No redundant information, front-loaded with the action, and every word adds value.
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 simplicity (3 required params, mutation, output schema exists), the description covers the essential purpose and parameter semantics. The output schema exempts return value explanation. However, some behavioral context (e.g., whether it overwrites existing rules) would improve completeness.
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?
The schema has no descriptions (0% coverage), so the description compensates well by explaining each parameter: task_type includes an example, tier enumerates valid values (haiku, sonnet, opus), and reason explains its purpose. This adds 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 the action ('Add or update') and the resource ('routing rule for a task type'). It effectively captures the tool's purpose and distinguishes it from sibling tools like 'recommend_model' and 'opus_test', though it does not explicitly differentiate.
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?
No guidance is provided on when to use this tool versus alternatives, nor does it mention prerequisites or when not to use it. This omission leaves the AI agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export verified chunks as JSON compatible with enrich-nodes.js.
Args: project: Optional project filter min_confidence: Minimum confidence level (seed, watered, sprouted). Default: watered
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | ||
| min_confidence | No | watered |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only indicates a read-like export operation. Does not disclose side effects, permissions, rate limits, or whether data is altered. Should explicitly note it is non-destructive.
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?
Two clear paragraphs: one-line purpose then bulleted parameters. No wasted words. Could integrate parameter descriptions more concisely but overall efficient.
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?
Covers two parameters adequately but lacks description of output format beyond 'JSON compatible with enrich-nodes.js'. No mention of pagination, limits, or error states. With no annotations, more detail on behavior would improve completeness.
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 0% schema coverage, description adds valuable meaning: 'Optional project filter' and enumerates confidence levels (seed, watered, sprouted) with default. However, could clarify format or valid values for project.
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 verb (export) and resource (verified chunks), and specifies output format compatibility with enrich-nodes.js, distinguishing it from sibling tools like submit_chunk.
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?
No guidance on when to use vs. alternatives like mark_reviewed or get_review_queue. Only describes optional parameters but lacks context on prerequisites or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get estimated cost report by model and project.
Args: project: Optional project filter
| Name | Required | Description | Default |
|---|---|---|---|
| project | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It adds that the cost report is 'estimated', hinting at non-exact values. However, it does not explicitly state that GET operations are read-only, nor does it discuss authentication, rate limits, or side effects.
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 very short and front-loaded, but the inclusion of 'model' without corresponding schema support introduces inaccuracy, undermining conciseness. The second sentence is redundant with the schema type.
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 simplicity (one optional parameter) and an output schema that may describe return values, the description still lacks context on what the cost report contains, how 'estimated' is defined, and typical use cases. It is incomplete for effective tool selection.
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 0%, so param descriptions are absent. The description merely restates the parameter name ('Optional project filter'), offering no additional semantics, such as required format, examples, or relationship to cost data.
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 states 'Get estimated cost report by model and project', clearly identifying the resource and action. However, it misleadingly mentions 'model' as a filter criterion, but the input schema only includes a project parameter, creating inconsistency and potential confusion.
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?
No guidance is provided on when to use this tool versus siblings like 'get_stats' or 'export_chunks'. There is no mention of prerequisites, context, or alternatives, leaving the AI agent without decision-making support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List chunks needing review.
Args: project: Filter by project node_type: Filter by node type confidence: Filter by confidence level (seed, watered) limit: Max results (default 50)
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | ||
| node_type | No | ||
| confidence | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden. It adequately implies a read-only operation ('list'), but does not disclose any side effects, permission requirements, or rate limits. The default limit of 50 is mentioned, which is mildly helpful.
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 extremely compact: one-line purpose then a compact list of parameters. Every word is informative, with no redundancy. The front-loading of the core function is excellent.
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 presence of an output schema, the description need not detail return values. All four parameters are covered, though there is no mention of sorting or pagination beyond the limit. It is sufficient for a straightforward list tool but lacks edge-case guidance.
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?
Input schema coverage is 0%, yet the description defines all four parameters with meaningful explanations (e.g., 'Filter by project', 'Filter by confidence level (seed, watered)'). This adds value beyond the bare schema types and defaults.
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 explicitly states 'List chunks needing review,' which is a specific verb-resource combination. It clearly distinguishes from sibling tools like 'mark_reviewed' and 'submit_chunk', which perform different actions.
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 no guidance on when to use this tool versus alternatives like 'mark_reviewed' or 'get_stats'. There is no mention of prerequisites, context, or exclusion criteria, leaving the agent without usage heuristics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get dashboard of chunk counts by confidence level and token usage.
Args: project: Optional project filter
| Name | Required | Description | Default |
|---|---|---|---|
| project | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states what the tool does, but fails to mention it is a read operation, any side effects, or required permissions. Output schema exists but behavioral details are lacking.
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 front-loaded with the core purpose in a single sentence, followed by parameter documentation. It is concise, though some additional context could be added without bloating it.
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 simplicity (one optional parameter, output schema present), the description is minimally adequate. However, it lacks explanation of 'chunk counts' or 'confidence levels', which could be assumed from context but not explicitly clarified.
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?
The description adds a basic meaning to the 'project' parameter ('Optional project filter'), but with 0% schema coverage, it should provide more detail on format, allowed values, or behavior when omitted. It does not fully compensate.
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 a dashboard of chunk counts by confidence level and token usage, distinguishing it from sibling tools like cancel_scheduled or export_chunks.
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?
No guidance on when to use or when not to use this tool compared to alternatives; no context provided on prerequisites or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View pending scheduled tasks.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states 'View pending scheduled tasks,' which implies read-only behavior but adds no extra context about pagination, ordering, or side effects. Given the trivial nature (no parameters), a score of 3 is appropriate.
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?
A single sentence that is front-loaded and contains no unnecessary words. Every word earns its place.
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 simplicity (no parameters) and the presence of an output schema (which documents return values), the description is complete enough to understand what the tool does and when to use it.
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 zero parameters, and schema description coverage is 100% (complete). Per the baseline rule for 0 parameters, score is 4. The description adds no param info but also needs none.
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 states a specific verb ('View') and resource ('pending scheduled tasks'), clearly distinguishing it from sibling tools like 'cancel_scheduled' and 'schedule_task' that involve different actions.
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?
No guidance is provided on when to use this tool versus alternatives (e.g., when to view scheduled tasks vs. cancel or schedule them). The description is purely definitional without context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Promote or reject a chunk after review.
Args: chunk_id: UUID of the chunk verified_by: Model or person that reviewed (e.g. "sonnet-4.6", "opus-4.6") new_confidence: New confidence level (watered, sprouted, rejected) review_notes: Optional rejection reason or reviewer comments
| Name | Required | Description | Default |
|---|---|---|---|
| chunk_id | Yes | ||
| verified_by | Yes | ||
| new_confidence | Yes | ||
| review_notes | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It discloses the tool modifies chunk state but does not describe consequences (e.g., whether the chunk becomes final, triggers workflows, or requires additional steps). No mention of permissions or reversibility.
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 concise with a clear first sentence and structured Args section. It omits unnecessary details and is front-loaded with the 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?
For a tool with 4 parameters and an output schema, the description covers input parameters adequately but does not mention what the tool returns or any side effects. Since output schema exists, missing return description is acceptable, but behavioral completeness is lacking.
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 0%, but the description's docstring provides meaningful context: chunk_id is a UUID, verified_by specifies reviewer identity, new_confidence lists the three options, and review_notes are optional. This adds value beyond the schema's raw types.
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?
Description clearly states the tool promotes or rejects a chunk after review, providing a specific verb and resource. While it differentiates from siblings like get_review_queue and submit_chunk, it does not explicitly distinguish from submit_chunk which may also modify chunk state.
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?
No guidance is provided on when to use this tool versus alternatives such as submit_chunk or retry_on_error. The description lacks context on appropriate scenarios or prerequisites for promoting versus rejecting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate structured review summary for the OpusTest workflow.
Groups all seed/watered chunks by type with source URLs, ready for Sonnet first-pass then Opus final-pass.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes a 'generate' action without clarifying whether it is read-only or has side effects (e.g., caching, state changes). It also omits any mention of required permissions or idempotency, leaving the agent uncertain about safe usage.
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, with two sentences that front-load the purpose and add detail. However, it uses jargon ('seed/watered chunks', 'Sonnet/Opus passes') that may not be universally understood, slightly reducing clarity.
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 no parameters and no annotations, the description is somewhat adequate but lacks information about the output format despite the existence of an output schema. The mention of 'structured review summary' is vague; the agent might benefit from knowing the summary's key fields.
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 zero parameters and 100% schema coverage, the description does not need to add parameter details. The baseline of 4 is appropriate as there are no parameters to explain; the description focuses on the tool's action.
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 that the tool generates a structured review summary for the OpusTest workflow, grouping chunks by type with source URLs. This distinguishes it from sibling tools like get_review_queue or submit_chunk. However, it could be more explicit about the scope (e.g., all chunks in the workflow).
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 implies usage in a multi-step workflow ('ready for Sonnet first-pass then Opus final-pass') but does not explicitly state when to use this tool vs alternatives like deliver_chunk or mark_reviewed. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get model recommendation for a task type.
Args: task_type: The type of task (e.g. "biography_synthesis", "fact_check_final")
| Name | Required | Description | Default |
|---|---|---|---|
| task_type | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must disclose behavioral traits. It only indicates read-only behavior but lacks details on side effects, prerequisites, or performance implications.
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?
Very concise with two lines, front-loaded purpose. Efficient but could include more context without adding bulk.
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?
Has output schema, so return value details are covered. However, lacks context on what constitutes a recommendation or constraints like minimum data needed.
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 0%, but the description's docstring adds examples for task_type (e.g., 'biography_synthesis'), providing meaning beyond the empty schema. However, it does not enumerate all possible values or validate input.
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 gets a model recommendation for a task type using specific verb 'Get' and resource. Siblings are diverse and unrelated, so differentiation is implicitly clear.
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?
No guidance on when to use this tool versus alternatives or when not to use. Description only states function without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record a failed attempt for a chunk and get retry guidance.
Call this when a model call fails (e.g. 500 error). Sprout tracks retry count and tells you whether to retry or escalate.
Args: chunk_id: The chunk ID that failed error_message: The error message from the failed attempt
| Name | Required | Description | Default |
|---|---|---|---|
| chunk_id | Yes | ||
| error_message | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavior. It mentions recording attempts and providing retry escalation guidance, but does not clarify side effects (e.g., idempotency, retry limits) or authorization 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 concise, front-loading the purpose and usage context. Every sentence adds value, and the argument list is clearly presented.
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?
The description covers purpose, usage, and parameters. With an output schema existing, the return value is handled externally. Minor gaps exist in behavioral details (e.g., retry count limits), but overall sufficient for a simple tool.
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 0%, but the description includes 'Args' with explanations for both parameters (chunk_id and error_message), adding meaning beyond the schema. It could be improved with examples or constraints.
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's purpose: record a failed attempt and get retry guidance. It specifies the triggering condition (model call failure, e.g., 500 error) and distinguishes itself from sibling tools like submit_chunk or get_stats.
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?
Explicitly states when to use ('Call this when a model call fails'). However, it does not mention when not to use or provide explicit alternatives among siblings, which are not error-related except this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Schedule a task to run at a specific time or after a delay.
Args: task_name: Task to run (opus_test, export_chunks, get_stats) run_at: ISO datetime for when to run (e.g. "2026-02-26T02:00:00-07:00") delay_minutes: Minutes from now to run task_params: Optional JSON string of parameters
| Name | Required | Description | Default |
|---|---|---|---|
| task_name | Yes | ||
| run_at | No | ||
| delay_minutes | No | ||
| task_params | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the parameter semantics but fails to explain behavioral traits such as whether scheduling is one-time only, confirmation or error handling, or side effects like overwriting existing schedules. The allowed task names are helpful, but core behavioral context is missing.
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 brief and structured with a lead sentence followed by bullet-point parameter docs. Every sentence is informative with no redundancy.
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 presence of an output schema, the description need not detail returns. However, it lacks mention of permissions, scheduling limits, or error cases. The parameter explanations are adequate but leave out real-world constraints.
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?
The schema has 0% description coverage, so the description must add meaning. It explains task_name values, run_at format, delay_minutes meaning, and task_params as optional JSON. This goes beyond the schema types, though it could clarify mutual exclusivity of run_at and delay_minutes.
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 verb 'Schedule' and the resource 'task', and it specifies the two modes (specific time or delay). It lists the allowed task names, which distinguishes it from sibling tools like cancel_scheduled and list_scheduled.
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 implies usage by stating the tool schedules a task at a time or after a delay, but it does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store content with provenance tracking.
Args: project: Project name (e.g. "theology") node_id: Node identifier (e.g. "cath-person-001") node_type: Node type (e.g. "Person", "Council", "Document") field: Field name (e.g. "biography", "description") content: The actual content produced_by: Model that produced it (e.g. "haiku-4.5", "sonnet-4.6", "opus-4.6") task_type: Type of task (e.g. "biography_synthesis") sources: URLs used as sources
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | ||
| node_id | Yes | ||
| node_type | Yes | ||
| field | Yes | ||
| content | Yes | ||
| produced_by | Yes | ||
| task_type | Yes | ||
| sources | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds context like 'provenance tracking' and parameter examples, but doesn't disclose side effects (e.g., idempotency, overwrite behavior) or required permissions.
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?
Purpose is front-loaded. The Args list is necessary due to no schema descriptions, making it longer but still structured. Could be slightly more concise by grouping examples.
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?
Covers core functionality and parameter meanings, but lacks info on return values (output schema exists but not described) and behavioral details like create-vs-update or error handling.
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 0%, but the description lists all 8 parameters with context and examples (e.g., 'Project name (e.g. "theology")'), fully compensating for the missing schema docs.
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?
Clear verb 'Store' and resource 'content with provenance tracking'. Sibling tools like 'export_chunks' and 'get_review_queue' have different purposes, so this is easily distinguished.
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?
No guidance on when to use this tool vs alternatives like 'export_chunks' or 'mark_reviewed'. The description only states what it does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.4cancel_scheduledconfigure_routingexport_chunksget_cost_reportget_review_queueget_statslist_scheduledmark_reviewedopus_testrecommend_modelretry_on_errorschedule_tasksubmit_chunkScored across 13 tools
All 13 tools have clearly distinct purposes: scheduling, routing, chunk operations, cost/stats, error handling, and model recommendations. No two tools overlap in functionality.
Most tools follow a consistent verb_noun pattern (e.g., submit_chunk, schedule_task). 'opus_test' is a slight outlier as it uses noun_noun, but it is a specific workflow name and not inconsistent with overall readability.
13 tools is well-scoped for a knowledge management system covering chunk lifecycle, routing, scheduling, and reporting. Each tool serves a distinct purpose without being overwhelming.
The tool set covers creation, review, export, scheduling, routing, and error handling. Lacks a direct tool to retrieve a single chunk by ID, but filtering in get_review_queue partially addresses this. Minor gap, not critical.
Sentiment, toxicity, entity extraction, PII, translation, summary, QA, fraud scoring, safety audit.
Enterprise AI Control Plane: governance, guardrails, spend tracking, compliance & smart routing.
AI routing, memory, guardrails, and governance. Routes across Claude, GPT, Gemini.
Cost-optimized LLM model routing recommendations for autonomous AI agents
