Skip to main content
Glama

Omnara

by com.omnara
OverviewDiscussions(1)Admin

Grant model to project

grant_models_add

Lets a project's agent configs use a configured model and returns the new grant. Optional overrides can narrow the model for that project (lower token limits, tools or reasoning turned off, fewer reasoning efforts or modalities) and set its per-request defaults within those limits.

Input Schema

NameRequiredDescriptionDefault
orgIDYesOrganization ID (org_...).
projectIDYesProject ID (proj_...).
supports_toolsNoOptional project-level tool-use gate. Can disable tools, but cannot enable tools when the configured model does not support them.
input_modalitiesNoOptional project subset of configured-model input types (text, image, or file). Empty or omitted means inherit.
max_output_tokensNoOptional project output-token ceiling. Cannot exceed the configured model's ceiling.
output_modalitiesNoOptional project subset of configured-model output types. Empty or omitted means inherit.
supports_reasoningNoOptional project-level reasoning gate. Can disable reasoning, but cannot enable reasoning when the configured model does not support it.
configured_model_idYes
context_window_tokensNoOptional project context budget for input and output tokens. Cannot exceed the configured model's budget. Triggers compaction when estimated input exceeds the remaining budget after output and safety reserves. The turn fails if compaction cannot make it fit.
default_cache_retentionNoPrompt-cache preference for model requests; `short` when omitted. `short` applies the route's default caching (explicit cache breakpoints where the provider requires them) and, where the route accepts one, a stable conversation key for cache-aware routing. `long` prefers the route's extended cache lifetime where one exists (currently Anthropic's one-hour cache, which on Bedrock requires Claude 4.5 or newer) and behaves like `short` elsewhere. `none` sends no Omnara-managed cache controls or conversation key; providers may still cache prefixes on their own.
default_reasoning_effortNoOptional project default reasoning effort.
default_max_output_tokensNoOptional project default per-request output-token cap.
supported_reasoning_effortsNoOptional project subset of configured-model reasoning efforts. If this excludes the inherited default_reasoning_effort, set default_reasoning_effort on the grant too.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / orgID / description
      Added value: +"Organization ID (org_...)."
    • addedInput schema / properties / projectID / description
      Added value: +"Project ID (proj_...)."
  2. Changed1 schema field changed
    • changedInput schema / properties / context_window_tokens / description
      Previous value: -"Optional project token-window limit. Cannot exceed the configured model's current limit."New value: +"Optional project context budget for input and output tokens. Cannot exceed the configured model's budget. Triggers compaction when estimated input exceeds the remaining budget after output and safety reserves. The turn fails if compaction cannot make it fit."
  3. First observed

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare a non-read-only, non-idempotent, non-destructive mutation. The description adds genuine value beyond that: overrides can only narrow the model (lower limits, disable tools/reasoning, fewer efforts/modalities) and set per-request defaults within those limits, and it states it returns the new grant.

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?

A single front-loaded sentence with the core action first and the override behavior second. It is dense but not padded; no filler sentences.

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

Completeness4/5

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

For a 13-parameter mutation tool with 92% schema coverage and no output schema, the description covers what the tool does, the narrowing semantics of the optional fields, and the return value. Gaps remain on permission requirements and duplicate/idempotency behavior, but the annotations partially cover the safety profile.

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

Parameters4/5

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

Schema coverage is 92%, so the baseline is 3. The description adds a useful conceptual layer by grouping the override params as narrowing-only and distinguishing model-wide limits from per-request defaults, helping the agent understand how the 10 optional fields relate rather than treating them in isolation.

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?

The description names a specific verb (grant) and resource (configured model to a project) and states the outcome ('returns the new grant'). It is clearly distinguishable from grant_models_delete and grant_models_edit by name and effect, though it never names a sibling explicitly.

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 explicit when-to-use guidance or routing to grant_models_edit/grant_models_delete, nor any prerequisites (permissions, existing grant behavior). The 'optional overrides can narrow the model' clause hints at constraints but does not tell the agent when this tool is the right choice.

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

All Omnara toolsInspect
Try in Browser
Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources