Loading ToolBench
MCP server for the Pl@ntNet plant identification API
PlantNet MCP demonstrates solid definition quality with well-structured tools, comprehensive parameter documentation, and clear action-verb naming. All three tools (identify_plant, list_projects, check_quota) have detailed descriptions (194-289 chars, within baseline 34-392 range) and complete input schemas with type definitions and constraints. The identify_plant tool includes advanced features like enums for organ types, min/max constraints for numeric parameters, and helpful guidance on multi-image usage. However, output schemas are not formally documented (responses are formatted as markdown strings rather than structured JSON), and error handling lacks explicit recovery guidance. Tool composition is sound, each tool has a single responsibility, names follow verb_noun pattern, and parameter naming is consistent (lang, project, nb_results). No tool accepts secrets as parameters. Overall, this is a well-executed specialist tool server that would function reliably in production, but falls short of A-grade (80+) due to missing output schema documentation and limited error recovery patterns.
Get information about Pl@ntNet API rate limits and quota. The free Pl@ntNet API allows 500 identifications per day per API key. The exact remaining count for today is returned as part of every identify_plant response. Use this tool when you need to understand quota constraints before batch processing.
Identify plant species from one or more photos using the Pl@ntNet AI. Provide image URLs and specify which plant organ appears in each photo. Returns ranked species matches with confidence scores, scientific and common names, taxonomic classification (genus, family), GBIF and POWO identifiers, and remaining daily API quota. Supports up to 5 images per request for improved accuracy. Example: identify a rose from a flower photo, or an oak from a leaf photo.
List all available Pl@ntNet flora databases (called projects or referentials). Each project covers a specific geographic region or taxonomic group. Use the project ID from this list as the "project" argument in identify_plant for more accurate region-specific identification. For example, if you know a plant is from Western Europe, use the "weurope" project.
Output schemas not formally documented. Tools return formatted markdown strings (formatIdentifyResult, etc.) rather than structured JSON with documented field types. LLMs cannot reliably extract or chain results without knowing field names/types in advance.
Error handling lacks actionable recovery guidance. No explicit error messages guiding LLMs on what to do if an API call fails (e.g., 'API quota exceeded, wait 24 hours before retry' or 'Image URL unreachable, verify URL is public').
identify_plant parameter 'organs' lacks explicit guidance on matching count with image_urls. While documented, the constraint 'Must have the same count as image_urls' should be validated with a clear error message if violated.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 64 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 50 | - | v1 |
No pagination support. list_projects and check_quota return complete lists with no limit parameter or cursor. If PlantNet API returns hundreds of projects, response bloat could waste tokens and degrade LLM reasoning.
identify_plant result limit (nb_results, max 25) is unconstrained at call time, tool description says higher values 'give more alternatives' but doesn't recommend a sensible default or explain performance/cost implications. Default of 5 is good, but agent could request 25 and bloat the response.