Simba MCP Server

Official

by getsimba-ai

Overview Schema Related Servers Score Discussions

Python

Hybrid

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.2
Disambiguation5/5
Every tool targets a distinct resource and action. get_model vs get_model_status vs get_model_results are clearly separated by result type (metadata, progress, analysis sections). run_optimizer vs run_scenario, and their respective get_* results tools, are unambiguous. Even related tools like update_run and set_run_pinned have distinct purposes (renaming/annotating vs pinning).
Naming Consistency5/5
Tool names follow a consistent verb_noun pattern throughout: get_, list_, create_, run_, set_, update_, rename_, save_, unsave_, delete_. All use snake_case, and similar operations are named uniformly (e.g., create_model/create_var_model, list_models/list_projects/list_runs/list_uploads, get_optimizer_results/get_scenario_results). No mixing of conventions.
Tool Count2/5
With 29 tools, the surface is large and exceeds the 'too many' threshold of 25+. While each tool serves a distinct purpose in a comprehensive MMM workflow, the sheer number is likely to overwhelm an agent and suggests a more granular API than necessary. The core functionality could be consolidated (e.g., merging run management tools or providing a single results fetch with section parameters).
Completeness4/5
The tool set covers the full MMM lifecycle: data upload/schema, model creation (MMM and VAR), linking, results retrieval (many sections), optimization, scenarios, run history, and project management. Minor gaps include no ability to delete runs or projects, no model config update (only create), and no data retrieval beyond schema, but these are not critical dead-ends. The core workflow is well-supported.
Average 4.6/5 across 29 of 29 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 43 commits in the last 12 weeks
- Last stable release on August 26, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds one genuinely useful behavioral trait, 'Idempotent', which tells the agent that repeated calls are safe and have the same effect. However, with no annotations at all, more context—such as whether unlinking is reversible or what happens if no link exists—would be needed for full transparency.
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?
The description is short and front-loaded with the core purpose. The '#569' reference is noise that doesn't help an agent invoke the tool, but the overall structure is otherwise excellent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter unlink operation, the description covers the basic action and includes an important idempotency caveat. It is minimally viable, but it leaves 'VAR link' undefined and offers no usage guidance or parameter clarification, so an agent is left to infer some context.
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?
The schema has a single required parameter, model_hash, with no description beyond its title. The tool description does not clarify what this hash represents, what format it should take, or how it relates to the MMM being unlinked, so it fails to compensate for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb, 'Remove', with a concrete resource, 'an MMM's VAR link', which makes the tool's purpose immediately clear. It also inherently contrasts with the sibling tool link_var_model, so an agent can tell them apart without further investigation.
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 is given about when to use this tool versus link_var_model or any other sibling. Although the operation is implied by the name, the description never states the conditions under which unlinking is appropriate or what prerequisites must exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It adds a useful behavioral detail: 'Legacy dashboard-saved configs are served verbatim.' However, it does not address what happens for invalid or missing model hashes, auth requirements, or possible transformations for non-legacy configs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two terse sentences with the main action front-loaded. The legacy-config note earns its place and does not add clutter, so the structure is efficient and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a low-complexity, single-parameter read tool, so a very long description is not required. Still, with no output schema and no annotations, the description leaves the return shape and error behavior to inference; mentioning the legacy verbatim case helps but does not fully complete the picture.
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 coverage is 0%, and the description does not explain 'model_hash' beyond associating it with a model. The parameter name is somewhat self-explanatory, but the description offers no guidance on where the hash comes from, its format, or how it should be supplied, leaving an uncompensated gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and identifies the resource ('stored contribution groups for a model'). It clearly differentiates this getter from the sibling 'set_contribution_groups' tool without needing to open schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for retrieving stored contribution groups, but it provides no explicit guidance on when to prefer it over alternatives or when it should not be used. The existence of a setter sibling is evident from the sibling list, but the description does not explicitly route the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the behavioral burden. It discloses the owner-only restriction, the 404 behavior for non-owned projects, and the important default-folder behavior after renaming. It does not mention the return value or side effects beyond that, but the key mutation behaviors are covered.
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?
The description is front-loaded with ownership and key caveats, followed by a clear Args section. Each sentence adds useful context, though the team-members example could be tightened without losing meaning.
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 simple two-parameter mutation with no output schema and no annotations, this description covers the critical context: who can rename, what error to expect, and what happens to the default folder. Missing return behavior is a minor gap, not a blocker.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It gives one-line explanations for both parameters, but 'project_id' and 'name' largely restate the schema titles. The only genuinely new information is 'see list_projects' and the word 'display' for the name, which is moderate compensation but not detailed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Rename a project you OWN,' which clearly identifies the verb, resource, and ownership constraint. It is distinct from the sibling rename_model, so an agent can tell this tool is for projects, not models.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context: owner-only access, 404 for projects you don't own, and a note that renaming the default folder is safe. It doesn't explicitly contrast with rename_model or say when not to use this tool, but 'see list_projects' gives a useful pointer for obtaining the correct project_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It goes beyond a generic status check by enumerating exact statuses (pending/under way/complete/failed) and specifying returned data: progress percentage, estimated time remaining, and timestamps. It does not discuss side effects or polling semantics, but 'check' and 'progress' make the non-mutating behavior reasonably clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-sentence purpose, a clear listing of return contents, and an Args block with the necessary parameter guidance. Every sentence adds actionable information and there is no filler.
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 low-complexity tool with one parameter and no output schema, the description covers purpose, return values, and parameter provenance sufficiently for correct invocation. It could be improved by explicitly contrasting with get_model_results, but nothing essential for calling the tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a bare type and title for model_hash, with 0% schema description coverage. The description compensates fully by explaining that model_hash is 'returned by create_model or list_models', giving the agent a precise way to obtain the required value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and a specific resource ('model') with a clear scope ('fitting progress'). It distinguishes itself naturally from siblings like get_model_results and list_models by focusing on progress rather than final outputs or metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by noting that model_hash comes from create_model or list_models, but it does not explicitly state when to use this tool versus alternatives such as get_model_results. There is no exclusionary guidance or conditional routing, so the usage is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It fully discloses the return payload, including the exact structure of columns and their intended downstream use for create_model, which is valuable behavioral context. It doesn't cover error cases or permissions, but for a simple retrieval tool the return contract is the most important behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and efficient: a one-sentence purpose statement, a compact return field list, and a short Args section. Every sentence adds value, and the most important information is front-loaded.
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 single-parameter getter with no output schema, the description is largely complete: it lists all returned fields and gives the one required input with provenance. It could be more explicit about read-only behavior or error conditions, but those are minor gaps given the simplicity of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines file_id as an integer with no description, so the description fully compensates. It explains that file_id is the upload's id and explicitly tells the agent where to obtain it (upload_data response or list_uploads), which is exactly the semantic meaning needed to call the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'one uploaded dataset's details', and highlights the column schema. This makes the tool's purpose immediately obvious and sufficiently distinguishes it from list_uploads (listing) and upload_data (creation), even though it doesn't explicitly name get_data_schema as an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives useful context by telling the agent that file_id comes from upload_data's response or list_uploads, and explains how the returned columns can be used to build create_model arguments. However, it does not explicitly state when to choose this tool over siblings like get_data_schema or list_uploads, leaving the comparison to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses validation rules (driver names validated against model factors, each driver in at most one group, baseAdjustments must reference own drivers), error behavior (400 with did-you-mean hint on typos), and the special pseudo-group. It does not mention side effects (overwrite vs append) or authentication, but the given details are substantial and specific.
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?
The description is longer than typical but every sentence delivers value: purpose, per-group schema, validation rules, pseudo-group, and an explicit disambiguation. The structure with bullets and a NOTE improves scanability. It is not overly verbose given the complexity.
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?
The description covers the essential input structure, validation rules, and the critical distinction from a sibling tool. It does not describe the return value (no output schema) or idempotency, but given the tool's complexity, the provided context is nearly comprehensive for correct invocation.
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 description coverage is 0%, so the description must compensate. It clearly explains the structure of contribution_groups (name, drivers, optional color, optional baseAdjustments, and the special pseudo-group) and gives validation constraints. It does not explicitly describe model_hash, but the name is self-explanatory and likely clear enough. Overall it adds strong semantic value beyond the loose schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (persist) on a specific resource (driver groupings for the dashboard contributions view) and clarifies its scope with context ('configure grouping once and every viewer sees it'). It also distinguishes this from the unrelated create_model channel_groups feature, so an agent can differentiate it from the sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly routes the agent away from create_model's channel_groups and clarifies this is the contributions-view grouping. It implies when to use (to set persistent dashboard groupings) but does not mention the read sibling get_contribution_groups or provide explicit 'use this when' conditions. The note about confusion adds clarity, so it's nearly a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden. It discloses that the tool returns a JSON Schema specification and enumerates the major contents (required columns, naming conventions, constraints, date formats). It also implies a read-only, side-effect-free 'get' operation, though it doesn't explicitly say so.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states the tool's purpose, the second lists exactly what the returned schema covers. Every sentence earns its place with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless getter, the description is complete: it names the resource, the return type, and the categories of information inside the returned schema. No additional detail about parameters or side effects is needed, and there is no output schema requiring separate explanation.
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?
The tool has zero parameters, so there are no parameter semantics to explain. The baseline for a no-parameter tool is 4, and the description adds meaningful context about what the returned schema contains without needing to document inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Get') and a specific resource ('canonical CSV data schema for Simba MMM input files'), and clarifies that it returns a JSON Schema specification. The scope is unambiguous and clearly distinct from sibling tools that handle runs, models, or uploads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes clear this is the tool to use when you need the schema for Simba MMM input files, which is useful context before uploading or validating data. It doesn't mention explicit exclusions, but no close alternative exists among the siblings, so no when-not guidance is necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explicitly reveals the key safety property: setting the current state again is a no-op and safe to re-run. It also explains run_id prefix conventions (opt_/scn_) and parameter roles, which adds meaningful behavior context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose, followed by the idempotence note, then a compact and structured Args list. Every sentence contributes useful information, with no filler or repetition of schema content.
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?
Given four required parameters, no schema descriptions, no annotations, and no output schema, the description covers the essential invocation details and the main behavioral guarantee. It could mention return behavior or error cases, but as a simple setter tool the provided information is sufficient for correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the Args section is the only explanation of parameters. It fully describes all four parameters: artifact with allowed values and id prefixes, model_hash, run_id, and pinned. This goes well beyond the bare schema and gives agents everything needed to populate the arguments correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Pin or unpin a saved optimizer or scenario run.' It clearly identifies the action and the two artifact types, and this is distinct from sibling tools such as run_scenario, get_scenario_results, and update_run. It is not a tautology and names the exact operation being performed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context by stating the tool is 'declarative and idempotent' and that 'scripts can safely re-run it,' which helps agents decide when repeated invocation is safe. It does not explicitly name alternatives or state when not to use this tool versus update_run, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the user-scoped nature of the list, the status/type fields returned, the include_unsaved behavior, and pagination semantics with default/max limits. It does not mention ordering or error behavior, but it provides substantially more behavioral transparency than a minimal description would.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and efficient: the purpose is front-loaded, the return fields are summarized in one sentence, a critical cross-tool note is set apart, and the Args block is compact and readable. Every sentence adds useful information, and there is no filler or tautology.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple list operation with three optional parameters and no output schema. The description covers what the tool does, what it returns, how to page, how to include unsaved models, and how the returned model_hash connects to all other model endpoints. Nothing essential for correct selection or invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only titles and defaults, with 0% description coverage. The description compensates fully by explaining each parameter: include_unsaved includes draft/unsaved models, limit is the maximum number with a default of 50 and max of 500, and offset is the number to skip for paging. This is exactly the meaning an agent needs beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'List all Marketing Mix Models for the authenticated user.' It goes on to enumerate the returned fields, making the tool's role clear and distinguishing it from narrower siblings like get_model or get_model_status. The scope is explicit, and the distinction between listing all models versus retrieving a specific one is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool by explaining that all other model endpoints require a model_hash and that list_models is the source of that hash: 'Use the model_hash from this response.' It does not explicitly name alternatives or exclusions, such as 'use get_model for a single model,' but the guidance is strong enough for an agent to infer the appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it is exceptionally transparent: it discloses async queuing, immediate hash return, polling needs, unsaved-model visibility, commit via save_model, strict validation (unknown keys rejected with 400), and the operating_margin_column root-caveat. It also explains resolved priors in get_model for verification.
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?
The structure is front-loaded with a one-paragraph summary followed by an Args block, and each parameter gets its own explanation, which is appropriate for 24 complex parameters. However, the description is long and includes internal ticket references (#630, #672, etc.) and repeated caveats that add noise without helping tool selection or invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a complex creation endpoint: it covers the async return contract, model state lifecycle, validation behavior, and all parameter semantics. Since there is no output schema, it correctly states that the return value is a model_hash for status polling; no critical invocation information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does: every one of the 24 parameters is explained, including defaults, valid values, mutually exclusive pairs, and cross-parameter constraints. The priors section in particular adds meaning far beyond the schema's bare additionalProperties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence states a specific verb and resource: 'Create and start fitting a new Bayesian Marketing Mix Model.' It also differentiates from siblings by describing the async fit-and-poll lifecycle with get_model_status and clearly separates this from create_var_model's domain. The purpose is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states exactly what happens on use: it queues an async fit and returns immediately, and directs the agent to poll get_model_status until 'complete'. It does not explicitly enumerate when to choose this over create_var_model, but the resource type ('Bayesian Marketing Mix Model') makes the context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral burden. It discloses the asynchronous nature ('Create and start fitting'), the return pattern ('Returns 202-style payload with model_hash; poll get_model_status'), data prerequisites ('at least lags + 10 rows'), strict parameter handling ('unknown keys are rejected'), and naming behavior ('honoured verbatim... falls back to generated API_VAR_*'). This goes well beyond a basic mutation description.
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?
The description is long, but the tool has 12 parameters and the length is mostly earned. It is front-loaded with a clear one-sentence purpose followed by structured Args. Minor noise includes issue-tracker references like '(#569)' and '(#575)', which don't aid an agent in calling the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 12-parameter tool with no output schema and no annotations, the description is remarkably complete: it explains the statistical purpose, the workflow position, every parameter's semantics, constraints, defaults, asynchronous return behavior, and the follow-up status-polling call. An agent has enough information to invoke this tool correctly and know what to do next.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate fully for the schema. It does: every parameter in the schema is listed in an Args block with its role, constraints, and inter-parameter restrictions (e.g., date_column cannot also be a series, exogenous_vars must not overlap endogenous_vars, base_variable must be endogenous, equity_variables excludes the base). This is exemplary supplementary guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Create and start fitting a long-term (VAR) model'. It also clarifies how this fits into the broader MMM workflow by mentioning the long-run elasticity bridge and explicitly telling the agent to link it with link_var_model, which differentiates it from the generic create_model sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when this tool is appropriate: 'VAR models capture the joint dynamics of several series... produce the long-run elasticity bridge behind the MMM's long_run_rollup results section.' It also gives workflow sequencing ('Fit one, then link it to an MMM with link_var_model'). It doesn't explicitly list exclusions or contrast against generic create_model, but the context is clear enough for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full behavioral burden and succeeds remarkably: it discloses CSV envelope structure, millisecond-epoch dates, per-section availability flags, version-dependent fields with no backfill, filtering exceptions, and the critical fact that results are keyed by activity-column names. It also warns about feature-detecting server-version differences rather than assuming hardcoded behavior.
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?
The description is very long, but the section-list format and Args block are highly structured and almost every sentence carries operational value. It loses a point because critical cross-cutting guidance—channel naming, epoch dates, and the context-size tip—is buried toward the end, so a truncating client could miss essential usage constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, no annotations, and many distinct result sections, this description is exhaustively complete. It documents shapes, key types, section availability, caveats, version differences, and even how to detect unavailable artifacts, leaving essentially no ambiguity about what calling this tool will return.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully document the parameters, and it does. Each parameter is explained in Args, including the meaning of model_hash, comma-separated sections, JSON vs CSV format with its return envelope, channel filtering semantics (case/space-insensitivity and the contributions exception), and max_grid_points striding behavior. This goes well beyond the bare input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence 'Get results from a completed model' gives a specific verb and resource, and the extensive section list concretely defines what kinds of results exist. It is clearly differentiated from sibling retrieval tools like get_optimizer_results and get_scenario_results, which are referenced only as sub-sections of this broader results endpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives strong practical usage guidance, such as recommending 'channel_summary,model_stats' for ROI and diagnostics, advising 'request only the sections you need' in conversational use, and explaining when mroi_periods is opt-in. It even includes behavioral prohibitions like never treating Overlap as a channel. However, it does not explicitly state when to choose this tool over get_optimizer_results or get_scenario_results, only pointing readers to those tools for those sections.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden and does so well. It reveals the permanent flip of the auto_named flag, the partial-update behavior, notes clearing semantics via empty string, and field constraints like the 255-character name cap and tag limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and then scoped through a clearly structured Args list. The short rationale with naming examples is not filler; it explains the permanent auto_named flag behavior that matters for using the tool correctly. No sentence is wasted.
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?
The description is complete for 6 parameters and covers required fields, allowed values, behavioral nuances, and constraints. The only notable gap is that it does not describe the return value or error behavior, which is relevant because there is no output schema and no annotations to supply that context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does. It explains every parameter beyond the schema: the artifact type and id prefixes, that model_hash identifies the run's model, the meaning of run_id, name as a non-empty capped display name, notes as clearable free text, and tags as a replacement list with size limits.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Rename / annotate a saved optimizer or scenario run.' It clearly distinguishes this tool from run execution, retrieval, and model/project rename tools among the siblings by naming the exact action and artifact types it operates on.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The first sentence gives clear context for when to use the tool: when a saved run needs renaming or annotating. It also explains why renaming is useful and clarifies that only provided fields are changed, but it does not explicitly name alternatives or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so thoroughly. It discloses name sanitization behavior, team membership requirements with specific 403/404 outcomes, and the 201 response including the returned ID. These non-obvious behaviors go well beyond what a bare 'create' description would provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, well-organized, and front-loaded with the core purpose. Each sentence earns its place: purpose, sanitization rule, parameter details, and return value/workflow. There is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter create operation with no output schema, the description is complete enough: it states the return status and ID, explains the optional team parameter and its failure modes, and shows how the result feeds into save_model. No critical information for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does. It explains that name is a display name subject to sanitization, and that team_id is optional, must belong to the caller, and yields specific error codes otherwise. This adds substantial meaning beyond the bare property titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Create a named project (model folder) to file models into.' It clearly distinguishes this from model-creation siblings by framing the project as a container for models, and the final sentence ties its purpose to save_model.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It does not explicitly enumerate when-not-to-use or alternatives, but it provides clear usage context: create a project as a destination for models, then pass the returned ID to save_model. The team_id constraint and error statuses further guide appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral burden and meets it thoroughly. It discloses that newer runs overwrite the latest scenario, that run_id-scoped results are immune to later runs, and that failed scenarios return status 'failed' with an error in the JSON body rather than as an HTTP error, even advising to always check the status field.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average but tightly organized with paragraph breaks and an Args list. Every section carries functional information, and the key distinction between run_id modes is placed early before the detailed response fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, this description is remarkably complete: it covers both call modes, response contents, failure semantics, parameter sources, and the overwrite pitfall. An agent has enough to select the correct form, construct arguments, and interpret results correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate, and it does. It explains model_hash as the model identifier and gives rich semantics for run_id, including its format ('scn_...'), its source, and how its presence changes the response shape and reliability of the result.
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 clearly states the tool returns scenario prediction results and distinguishes two modes: latest scenario state versus a specific saved run identified by run_id. However, it does not explicitly differentiate this tool from the sibling get_model_results, relying on the 'scenario' resource framing rather than naming the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance for both forms: without run_id for the latest model-level scenario, and with run_id when polling your own run or disambiguating back-to-back scenarios. It also explains where run_id comes from (run_scenario or list_runs) and warns about the overwrite behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so thoroughly: it discloses side effects (map replacement, unlink clearing), the pro-rata allocation rule, exact-name matching, strict validation rules, and the error naming the current owner for an already-linked VAR.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but front-loaded: one-sentence purpose, then behavior, then validation, then args. The length is justified by the tool's complexity (group allocation, map lifecycle, strict validation) and every paragraph adds operational information rather than repeating schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters, no annotations, and no output schema, the description provides enough for a correct call: required vs optional args, channel_map semantics, validation, ownership constraint, and resulting behavior in get_model_results. No critical operational gap is apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the Args section must compensate. It defines model_hash as the MMM to attach, var_model_hash as the VAR from create_var_model, and explains channel_map's shape, optionality, validation, and link-scoped lifecycle. This goes well beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Link a completed VAR model to an MMM.' It clarifies the linking relationship and its observable effect on get_model_results, and the restrictions distinguish it from unlink_var_model and other model tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains why linking is useful (long_run_rollup joins VAR elasticities with MMM revenue), when channel_map is required ('required whenever the VAR is fitted on group spends ... while the MMM is tactic-level'), and notes the one-link-per-VAR constraint. It does not explicitly say 'use unlink_var_model to remove a link,' though the unlink behavior is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it delivers: it discloses the 202 async contract, error conditions (missing margin), internal normalization of laydown weights, engine fallback behavior, and group-bound side effects on marginality semantics. This goes well beyond what the schema alone could reveal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long, but every section earns its place for a 16-parameter optimizer with significant constraints. It front-loads the main purpose, then groups related warnings in IMPORTANT bullets and documents each arg consistently. No filler or repeated schema text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex async tool with 16 params, nested objects, and no output schema, the description is complete: it covers all required inputs, prerequisite discovery steps, post-invocation polling, and key result-field semantics. An agent has enough context to invoke correctly and know what happens next.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description compensates for every parameter: gamma's formula and typical range, bounds as percentages with a worked example, laydown_weights/period_cpm array-length requirements, forward_margin's precise conditions, and even optimizer_engine behavior. This is exemplary parameter-level documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Run budget optimization on a completed model' and immediately states the outcome ('optimal budget allocation across channels to maximize predicted revenue — or predicted PROFIT'). This unambiguously distinguishes it from scenario-running or model-building siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear workflow context: call get_model_results or get_scenario_template first to obtain channel names/CPM, and poll get_optimizer_results after the 202. It does not explicitly contrast with run_scenario, but the prerequisites and post-steps are strong enough guidance for correct use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden, and it does so thoroughly. It reveals the async 202/pending behavior, the need to poll until completion, the NaN failure mode, the rebuild_model requirement for API-initiated scenarios, and the performance implications of skip_slicing. No annotation contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Though lengthy, the description is efficiently organized: a one-line summary, a critical NaN warning front-loaded, an async note, a compact workflow, then per-parameter details. Every sentence adds necessary information, and headings/separators make the size navigable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex async tool with no output schema and zero schema-level parameter help, the description is remarkably complete. It covers prerequisites, input format, parameter semantics, failure conditions, async polling, and the intended workflow. An agent has nearly everything needed to call the tool correctly and interpret the follow-up step.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% property description coverage, so the description must compensate for all seven parameters. It does this completely: model_hash is explained, scenario_data has a concrete example and format details, spend_metadata shows the exact per-entry structure, and each boolean parameter gets its meaning and default. This is exemplary parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pairing: "Run a what-if scenario prediction on a completed model." It clearly distinguishes this from siblings by naming the workflow (get_scenario_template -> run_scenario -> get_scenario_results) and by clarifying that channel names come from the template/results, not from create_model.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives strong usage context: use get_scenario_template first, then modify values, then run_scenario, then poll get_scenario_results. It also states the async polling requirement. It does not explicitly say when not to use run_scenario versus a sibling like run_optimizer, so it misses the full 5, but the workflow guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden, and it does so thoroughly. It discloses side effects (saving files the model into a project), the saved-models cap with the specific 400 error_type 'saved_limit', the fact that re-saving renames/refiles without consuming a new slot, and ownership/sharing requirements for project_id.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: a one-sentence summary is followed by a concise behavioral context paragraph, a cap/error note, and a three-item Args block. Every sentence adds information needed for correct invocation, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter mutation tool with no output schema, the description covers all required inputs, optional inputs, defaults, constraints, side effects, error behavior, and relevant sibling tooling. Nothing an agent needs in order to select and invoke this tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no per-parameter descriptions, so the description's Args section must add meaning. It does: model_hash is defined as the hash of the model to save, name is a non-empty display name, and project_id is optional, scoped by ownership/sharing, and defaults to the default project. This fully compensates for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Save a model into a project under a display name.' It also clarifies the otherwise subtle purpose by explaining that API-created models are unsaved until this call, and that saving makes them visible in list_models and the dashboard. This clearly distinguishes it from sibling operations like unsave_model and rename_model.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: API-created models start unsaved and need this call to appear in default listings. It also points agents to list_projects and create_project for discovering/creating project IDs. However, it does not explicitly contrast the tool with rename_model or unsave_model, so some alternative selection guidance is left implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and succeeds: it discloses irreversibility, the 409 error behavior for non-failed models, side effects on linked MMMs, removal of stored artifacts, and the exact success response shape. This is exemplary for a destructive mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence earns its place: the destructive warning is front-loaded, followed by status constraints, side effects, response format, and a pre-check hint. The Args section is minimal and directly tied to the parameter. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no annotations and no output schema, the description fully equips the agent to invoke the tool correctly: when it is allowed, what happens on failure, what side effects to expect, what response to expect, and how to avoid mistakes. Nothing essential is missing.
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 0%, so the description must compensate. It does so by clarifying that model_hash refers to the hash of the FAILED model to delete, adding meaning beyond the bare string type. For a single simple parameter this is sufficient, though not deeply detailed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('permanently delete') and resource ('FAILED model'), clearly distinguishing it from read-only sibling tools like get_model and get_model_status. The capitalization and 'destructive and irreversible' warning make the operation unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states the only valid use case: deleting models with status 'failed'. It also names the alternatives to check first (get_model, get_model_status) and explains that other statuses return a 409, so the agent knows when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility, and it discloses key behaviors: it returns data for any status, error is non-null only when status is 'failed', and the configuration echo omits some accepted create_model inputs. This is substantive behavioral context beyond the bare 'get' action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the essential scope and usage, then organized into returns and caveats with clear formatting. The length is justified because there is no output schema to carry the return-field details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool with no annotations and no output schema, the description provides comprehensive detail: behavior, return fields, failure semantics, and a known caution about omitted echo fields. Nothing required to call it correctly is missing.
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?
The only parameter, model_hash, is described in Args with the added semantic 'any status', clarifying that the tool works with failed models. Schema coverage is 0%, but the single parameter is simple and the description gives enough context for correct invocation, though it does not give a format or example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence names the action ('Get'), the resource ('model's metadata and configuration echo'), and scope ('works for EVERY status, including failed models'). It explicitly differentiates from get_model_results, which needs status 'complete', so an agent can disambiguate without reading definitions of other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states concrete use cases: inspect configuration, diagnose failure, or locate a model. It also names the alternative get_model_results as not applicable to failed models, giving an explicit when/when-not condition. The note about checking financials results for stored margin adds additional guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden and does so thoroughly. It discloses that only owned and team-shared projects are returned, the exact fields per project, the 'shared' flag behavior, the meaning of model_count (SAVED models, not all models), and the intentional absence of delete in the API.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact but information-dense, with a clear progression: what the tool lists, what it returns, how to use the ids, and the one intentional API limitation. Every sentence adds value; nothing is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-argument tool with no output schema and no annotations, the description is complete. It explains the return payload, field semantics, downstream usage, and the missing delete capability. An agent could invoke this correctly with no further information.
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?
The tool has zero parameters, so there is nothing meaningful to document; the baseline for parameter semantics is therefore 4. The description correctly focuses on output semantics instead, which is appropriate for a parameterless list operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'List the projects (the app's model folders) you can file models into.' This clearly states what the tool does and clarifies what a 'project' is in domain terms. It is distinct from sibling tools like save_model or rename_project, and the follow-up about ids reinforces that distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent how to use returned ids: 'Use the ids with save_model(project_id=...) and rename_project.' It also provides an important when-not: 'There is deliberately no delete over the API — use the app to delete a project.' This gives practical guidance beyond a bare list function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure. It states that only the display name changes, that the saved/unsaved state is unaffected, that the name is HTML-sanitized server-side, and that it must be non-empty. These are concrete behavioral traits beyond the basic rename operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tight and well-structured: one summary line, a two-sentence behavioral clarification, and a two-line Args list. Every sentence adds value, and there is no redundant filler.
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 simple two-parameter rename tool with no output schema, the description covers purpose, behavior, parameter meanings, and constraints. The only minor gap is the absence of return-value or error-condition details, but nothing essential is missing for making a correct call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by defining both arguments: 'model_hash: Hash of the model to rename' and 'name: New display name.' This gives the agent precise meaning for each parameter, plus the text adds the non-empty constraint on name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Rename a model,' a specific verb and resource, and immediately distinguishes itself from siblings by stating 'Changes only the display name; the model's saved/unsaved state is untouched.' This makes it clear this tool is not save_model or unsave_model, which are present in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides a when-not-to-use signal: 'the model's saved/unsaved state is untouched (use save_model to file it into a project).' This directs the agent to the correct alternative and clarifies the exact boundary of this tool's responsibility.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure burden and handles it thoroughly: no deletion, state transition, retention of hash-addressability, visibility changes, idempotent behavior, auto-pruning consequences, and shared-model implications. This is exemplary for a state-changing tool lacking annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average, but every section contributes: core definition, use-case context, state semantics, caveats, return shape, and parameter explanation. The most important information is front-loaded, with caveats and details logically arranged.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is remarkably complete: it specifies the return value, side effects, idempotence, lifecycle interactions, and edge cases. An agent has everything needed to decide when to call this tool and what to expect.
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 0%, so the description must compensate. The Args block explains that model_hash is 'the hash of the model whose slot to release,' which adds meaning beyond the bare string type. It could have specified how the hash is obtained (e.g., from create_model or list_models), but the semantic role is clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb-resource pair: 'Release a model's saved slot without deleting anything' and explicitly frames it as the inverse of save_model. This clearly distinguishes it from delete_model and other siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete when-to-use guidance: cap management at the 20-saved-models limit, unsave rather than delete when a model no longer earns its slot. It also contrasts with delete_model, states idempotence, and warns when unsaving is risky (shared models, auto-pruned unsaved pool).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does so thoroughly. It discloses the overwrite hazard, explains the meaning of result columns, warns against mixing incompatible metrics, and notes that placeholder arrays are stripped server-side.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but structured with clear headings, bullets, and mode-based sections. Every section adds necessary information about behavior, parameter usage, or result semantics, and the opening sentence immediately states the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, this description is exceptionally complete. It covers both invocation modes, return key structures, column interpretation pitfalls, and parameter semantics, leaving an agent well-equipped to call the tool correctly and interpret its results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains run_id's provenance from run_optimizer's response, its purpose for polling a specific run, and its optional/default nature. model_hash is described as the hash of the optimized model, which is sufficient given the schema's required string field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Get budget optimization status and results.' It clearly distinguishes the two modes (model-level latest run vs. specific run via run_id) and ties to run_optimizer, making the tool's purpose unmistakable even among many siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when to use each form: without run_id for the latest model-level state, with run_id to poll a specific run. It warns that a newer run can overwrite the latest view and explicitly tells the agent to poll with run_id when it needs to know whether its own run completed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral burden and does so comprehensively. It discloses response contents, field-by-field meaning, the NaN/null risk, mandatory preprocessing before passing data downstream, and the consequence of ignoring the warning.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with a summary, an important usage block, a response-fields note, a warning, and parameter definitions. Despite substantial content, it is front-loaded and every section earns its place; no filler or vague language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description is unusually complete. It covers purpose, prerequisite usage, return fields, parameter semantics, an edge-case warning, and downstream integration details. An agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It describes model_hash as 'Hash of a completed model' and periods_forward as 'Number of future periods to generate (default 12),' adding domain meaning that the bare schema does not provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with a specific verb and resource: 'Generate a forward-period scenario template from a completed model.' It clearly enumerates what the response contains and positions the tool as a prerequisite for run_scenario and run_optimizer, which distinguishes it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States explicitly 'IMPORTANT: Always call this before run_scenario or run_optimizer' and then lists exactly what to discover and how to use those values downstream. This gives an agent unambiguous when-to-use guidance and prevents misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden, and it does so thoroughly. It reveals the exact response shape, ordering (pinned-first, newest-first), the non-obvious page-local meaning of `count`, and the missing optimizer objective caveat. It also documents API clamping on limit, which is exactly the kind of behavioral detail an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every section earns its place: Returns, Ordering, CAVEATS, alternative tool routing, and Args. The one-sentence purpose is front-loaded, and the caveats are truncated to the two genuinely non-obvious behaviors rather than enumerated exhaustively. Structure with labeled sections makes it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description is essentially complete on its own. It defines the top-level return object, run summary fields including key_metrics examples, nullable key behavior, ordering, paging semantics, and caveats that would otherwise cause incorrect agent behavior. The only minor omissions (e.g., status enum values) are not necessary for successfully calling and interpreting this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate; it does. Each parameter is given meaningful semantics: artifact values with run id prefixes, model_hash purpose, limit page size with API clamp and default, and offset as rows to skip for paging. This far exceeds the bare type/title information in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'List a model's saved optimizer or scenario run history.' It also distinguishes itself from sibling tools by explicitly pointing to get_optimizer_results/get_scenario_results for fetching full run details. The artifact types ('optimizer' vs 'scenario') further clarify scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage guidance is explicit: use this tool to list run summaries, and use get_optimizer_results / get_scenario_results with a run_id when full inputs and results are needed. It also names update_run / set_run_pinned for curation and warns to page until a short page, which is actionable routing to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it delivers: newest-first ordering, inclusion of all source types, true-total count behavior, API clamping of limit, and the explicit absence of column names/dtypes. It also notes the id field's role for create_model, which is valuable behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured and efficient: overview, return shape, caveats, and argument details. Every sentence adds information an agent needs, including the count-vs-page-length warning and the pointer to get_upload for deeper metadata.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, but the description defines the complete return shape ({files, count, limit, offset}) and every field on each file. It also covers pagination, filtering, and the next-step alternative, making it fully actionable for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only defaults and no descriptions, so there is 0% schema coverage. The description fully compensates by explaining limit with clamping and default, offset as paging, and name as a case-insensitive substring filter on the original filename.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'List the datasets in your workspace (newest first)'. It also distinguishes this tool from siblings by clarifying it covers every source type, not just API uploads, and from get_upload by stating what this listing does and does not include.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when this tool is appropriate: listing datasets with pagination and filtering. It explicitly directs the agent to get_upload when column names/dtypes are needed, and it distinguishes the count semantics from list_runs to prevent misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral transparency burden. It discloses the 10 MB API-enforced limit, CSV-only restriction, authoritative warnings field, required media column naming conventions, zero-fill requirement for inactive periods, and the local-only availability of csv_path. This goes well beyond a minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every block earns its place: a one-sentence summary, a clarity rule, structured constraints, and a compact Args section. Important caveats are front-loaded and highlighted with 'IMPORTANT', so an agent can quickly identify critical requirements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema and no annotations, the description tells the agent what the tool returns (uploaded file ID needed for create_model, row/column counts, validation warnings) and points to get_data_schema for the canonical input format. This is complete enough for an agent to invoke the tool correctly in most environments.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 0% of the parameters, so the description must compensate, and it does thoroughly. It explains csv_content as raw CSV text, csv_path as a server-readable file path, name's default behavior from the file stem, and filename's purpose as a recorded original filename. It also adds the exclusivity constraint between csv_content and csv_path.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Upload'), a resource ('CSV dataset to Simba'), and its purpose ('for use in model building'). This clearly differentiates it from sibling tools like list_uploads, get_upload, and create_model by focusing on the ingestion step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: provide exactly one of csv_content or csv_path, prefer csv_path for large data, and check get_data_schema for row minimums. It also specifies when csv_path is unavailable (HTTP/SSE deployments), making the selection context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![simba-mcp MCP server](https://glama.ai/mcp/servers/getsimba-ai/simba-mcp/badges/card.svg)](https://glama.ai/mcp/servers/getsimba-ai/simba-mcp)

Score Badge

Copy to your README.md:

[![simba-mcp MCP server](https://glama.ai/mcp/servers/getsimba-ai/simba-mcp/badges/score.svg)](https://glama.ai/mcp/servers/getsimba-ai/simba-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/getsimba-ai/simba-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server