This server provides two MCP tools for farming cooperative support in Mali: crop market prices and pest information.
get_market_price: Get the latest price per kg (in FCFA) for maize, rice, millet, or sorghum. Optionally filter by market/town; otherwise returns prices for all markets. Output includes market, town, region, price, observation date, and source, with an is_demo_data flag indicating fictitious data.
get_pest_sheet: Fetch a detailed, hand-written pest sheet by ID (e.g., "maize-fall-armyworm"). Returns symptoms, prevention, cultural and biological controls, season, severity, affected crops, sources, and a fixed treatment_guidance text to repeat verbatim—no treatment recommendations are generated.
Safety features: Pest sheets are scanned for dosages and trade names before loading; CI also scans outputs. The server refuses unsafe sheets.
Demo data: Prices are fictional demo data flagged as such; pest sheets have a review_status ("sourced" = not yet agronomist-reviewed).
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., "@sene-mcp What's the price of millet per kg in Bamako?"
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.
English · Français
Work in progress — v0.1 under construction. Lot 1 of 3: server skeleton, 2 tools, CI.
An MCP server that gives AI agents safe, sourced tools for farming cooperatives in Mali: crop pest guidance and market prices.
Sɛnɛ means "to farm" in Bambara.
Tools know, the agent talks. Tools return facts from hand-written, cited pest sheets. They never generate advice.
Safety is enforced twice. Every string of every pest sheet is scanned for dosages ("20 ml pour 15 litres", "1 sachet par pompe"…), active ingredients and trade names: the server refuses to load a sheet that fails, and CI also scans every tool output. The word list is a safety net, not a guarantee; sheets are written and reviewed by hand.
Honest data. Prices in this version are fictitious demo data, flagged is_demo_data: true in every answer.
Ports and adapters. The domain has no dependency on MCP, the database or any AI provider.
Related MCP server: Plantos MCP Server
Tool | What it returns |
| Latest price per kg, in FCFA, per market (maize, rice, millet, sorghum) |
| Symptoms, prevention, non-chemical control and sources for one pest |
Coming in lot 2: diagnose_symptoms, analyze_photo, report_pest, publish_offer, search_offers.
Requires uv.
git clone https://github.com/ibrahko/sene-mcp.git
cd sene-mcp
uv sync
uv run sene-mcp # starts the server on stdio and waits for a client (Ctrl+C to stop)On first run the server creates its SQLite database with demo data in a per-user folder
(Windows: %LOCALAPPDATA%\sene-mcp, macOS: ~/Library/Application Support/sene-mcp,
Linux: ~/.local/share/sene-mcp), whatever the current folder. Override with SENE_DATA_DIR
or SENE_DATABASE_URL (see .env.example). uv run sene-mcp-seed prepares it without
starting the server.
To use it from Claude Desktop or any MCP client, launch it with an absolute project path:
uv --directory /path/to/sene-mcp run sene-mcpTry it with the MCP Inspector:
npx @modelcontextprotocol/inspector uv run sene-mcpuv run pytest # tests, including pest-sheet safety and architecture checks
uv run ruff check . # lint
uv run ruff format --check . # formatting
uv run mypy # types (strict)
uv run alembic upgrade head # migrations, for developmentIbrahima Koné — backend Python & AI engineer, Bamako, Mali
GitHub · LinkedIn
MIT © 2026 Ibrahima Koné
Latest price per kg, in FCFA, of a crop product on Malian markets.
| Name | Required | Description | Default |
|---|---|---|---|
| market | No | Market name or town, e.g. "Ségou". Omit to get all markets. | |
| product | Yes | Crop product to price |
| Name | Required | Description |
|---|---|---|
| unit | No | |
| prices | Yes | |
| product | Yes | |
| currency | No | |
| is_demo_data | Yes | True if any price is fictitious demo data |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It states the tool returns data, implying a read-only operation, but does not explicitly confirm non-destructiveness or mention authentication or rate limits. For a simple query tool, the absence is not misleading but leaves room for more transparency.
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 a single, concise sentence that immediately states the key elements: latest price, unit, currency, and geography. There is no redundancy or filler, and the essential information is front-loaded.
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 the core purpose and scope, and the schema handles parameter details. The output schema exists, so return format is not required in the description. The only minor omission is not explicitly stating that omitting the market parameter returns all markets, but that is documented in the schema. Overall, sufficient for correct invocation.
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 100%, with both parameters fully documented (product enum, market optional with default). The tool description adds no parameter-specific meaning beyond what the schema already provides, so the baseline of 3 applies.
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 retrieves the latest price per kg in FCFA for a crop product on Malian markets. It specifies the resource (crop product price), unit, currency, and geography, and is distinct from the sibling get_pest_sheet which concerns pests. No ambiguity remains.
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 does not explicitly contrast with get_pest_sheet, but the purpose is self-evident: use for market price queries. There is no mention of when not to use it or prerequisites, but the context is clear enough for an agent to infer appropriate usage. A minor gap in explicit routing guidance prevents a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full pest sheet: symptoms, prevention and non-chemical control, sources.
Treatments are never described: repeat `treatment_guidance` as is.
| Name | Required | Description | Default |
|---|---|---|---|
| pest_sheet_id | Yes | Sheet id, e.g. "maize-fall-armyworm" |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| kind | Yes | |
| crops | Yes | |
| season | Yes | |
| name_bm | Yes | |
| name_fr | Yes | |
| sources | Yes | |
| severity | Yes | |
| symptoms | Yes | |
| management | Yes | |
| is_demo_data | No | |
| review_status | Yes | 'sourced' = not yet reviewed by an agronomist |
| scientific_name | Yes | |
| treatment_guidance | Yes | Fixed referral text: repeat it as is |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key limitation: treatments are never described, and instructs agents to repeat treatment_guidance as is. Since no annotations exist, this adds meaningful behavioral context. It does not cover broader concerns like auth or rate limits, but for a read-oriented tool with an output schema, this is acceptable.
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 sentences with no filler. The primary purpose is immediately stated, and the critical treatment rule is delivered in the second sentence without 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 single fully described parameter and the presence of an output schema, the description adequately covers the tool's content and the special treatment_guidance instruction. It does not define treatment_guidance itself, but that likely appears in the output schema, so the gap is minor.
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 already fully describes pest_sheet_id with constraints and an example. The description adds no additional parameter-level meaning, so the baseline of 3 for full schema coverage applies.
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 the resource ('full pest sheet') and enumerates its contents (symptoms, prevention, non-chemical control, sources). This clearly distinguishes it from the sibling get_market_price, which concerns market pricing.
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 explicit guidance on when to use this tool versus alternatives. The sibling tool is not mentioned, and no selection criteria are provided. The only instruction refers to treatment_guidance handling, which is a behavioral rule, not usage context.
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.0get_market_priceget_pest_sheetScored across 2 tools
The two tools have completely distinct purposes: one provides market prices, the other provides pest information. There is no overlap or ambiguity in their intended use.
Both tools follow a consistent get_verb_noun pattern (get_market_price, get_pest_sheet). The naming is clear, predictable, and uses the same convention throughout.
With only two tools, the server feels thin and borderline for a coherent toolkit. While it might serve a very narrow niche, the count is at the low end of the acceptable range.
The tools cover market prices and pest sheets, but agricultural information typically includes other aspects like weather, planting tips, or crop recommendations. Notable gaps exist, though the two provided functions are themselves self-contained.
Pay-per-call safety checks for AI agents: screen a crypto address or URL before you transact.
Free verified network knowledge for AI agents: deterministic answers, honest unknowns.
Agent-first marketplace for real-world assets — agro and energy first; humans approve every write.
Prompt-injection scanning and safe webpage fetching for AI agents reading untrusted content.
