Skip to main content
Glama
Tandoor Recipes MCP

Tandoor Recipes MCP

by Cliftonz

Get current space

get_current_space
Read-onlyIdempotent

Retrieves the space currently active for the API token so agents can target the correct Tandoor Recipes workspace, with optional slim or full detail.

Instructions

Get the space currently active for this API token.

Input Schema

NameRequiredDescriptionDefault
formatNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv3.4.0

TDQS

C2.9/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint and closed-world behavior, so the safety profile is covered. The description adds only that the result depends on the calling token's active space, which is genuinely useful context, but says nothing about the response shape or whether the space can change between calls.

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?

One front-loaded sentence with no filler. It is as short as it can be, though its brevity is arguably under-specification rather than disciplined conciseness.

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?

There is no output schema, so the description carries the burden of explaining what a 'space' is and what the caller receives, and it does neither. The only parameter is also left unexplained, leaving an agent unable to predict the result or choose a format.

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?

Schema description coverage is 0% and the single 'format' parameter (enum slim/full) is completely undocumented in both schema and description. The description does not explain what slim versus full returns, which is exactly the information an agent needs to choose a value.

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?

States a specific verb and resource ('Get the space') with the scoping qualifier 'currently active for this API token', which no sibling tool duplicates. It is clear what the tool returns conceptually, though what a 'space' contains is never defined.

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?

No guidance on when to call this versus other context/introspection tools (e.g. get_version) or what an agent should do with the result. The token-scoping hint implies a purpose but does not state a use condition.

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