Skip to main content
Glama

organizer_tools_get_one_by_slug

Retrieve an organizer tool by its slug to access its configuration for organizing recipes or meal plans.

Instructions

Get One By Slug — Organizer: Tools. Get tool. [GET /api/organizers/tools/slug/{tool_slug}] Keywords: organizer_tools_get_one_by_slug, organizer tools get one by slug, get tool, fetch tool, read tool, retrieve tool, view tool, show tool, tool, tools, organizer tools, organizers, slug, get, fetch, read, retrieve, view, show, read-only, mealie.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tool_slugYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.11

TDQS

C2.3/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full disclosure burden. It only hints at behavior via 'read-only' and the '[GET ...]' endpoint; it says nothing about auth requirements, error handling, or what happens when the slug is unknown.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The front-loaded title and endpoint are fine, but the large keyword block ('organizer_tools_get_one_by_slug, organizer tools get one by slug, get tool, fetch tool...') is pure filler that adds length without information.

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

Completeness2/5

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

For a simple slug lookup this is thin: no output schema, no annotations, and the description explains neither the slug format nor anything about the returned tool. An agent gets the endpoint but little else to invoke it confidently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With one required parameter and 0% schema description coverage, the description must explain tool_slug. It only surfaces the parameter name in the URL template and the 'slug' keyword, giving no format or identity semantics beyond the schema's field name.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

"Get tool" states a verb and resource, and the endpoint template implies a slug-keyed lookup. However, it essentially restates the tool name and never explains how this differs from the sibling organizer_tools_get_one, so the purpose is vague rather than distinguishing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no indication of when to use this tool versus organizer_tools_get_one or organizer_tools_get_all. The keyword list ('fetch tool, read tool, view tool...') is retrieval-noise, not usage guidance or alternatives.

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

Deploy Server

Other Tools