STATA-MCP Repro

by taewat07

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Active tools have distinct purposes across planning, project management, run lifecycle, data inspection, and output retrieval. Deprecated tools are clearly labeled with redirecting messages, so misselection is unlikely despite some overlap in names.
Naming Consistency3/5
All tools use snake_case, but there is a clear split: active tools favor object_verb naming (e.g., run_prepare, data_inspect) while deprecated tools use verb_object naming (e.g., write_dofile, read_file). This mixed pattern reduces readability, though deprecated markers mitigate confusion.
Tool Count3/5
The total of 22 tools is heavy, and 9 of them are deprecated, artificially inflating the surface. The active 13 tools form a well-scoped set, but the obsolete entries should be removed to bring the count into an ideal range.
Completeness4/5
The active tool chain covers the full reproducibility lifecycle: plan preparation and approval, project initialization, run preparation/execution/monitoring, and artifact retrieval. Minor gaps like lack of list operations for runs or projects are workable.
Average 2.8/5 across 22 of 22 tools scored. Lowest: 1.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 31 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under AGPL 3.0.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden, but it only says the tool is removed. It does not disclose what happens when invoked, whether it has side effects, or what the 'Removed' state means for callers (e.g., error or no-op).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but it is under-specification rather than well-structured. The phrase 'Removed:' is abrupt and the remainder is not a clear functional description, so the brevity does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter, no annotations, and an output schema, the description fails to provide essential context about the tool's purpose, behavior, or return value. It is not complete enough for an agent to correctly select or invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines a single 'path' parameter with no description, and schema description coverage is 0%. The description never mentions 'path' or any arguments, so it adds no semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Removed:' which indicates the tool is deprecated rather than describing a function. The phrase 'initialize a project once; server owns artifact directories' is ambiguous about what the tool actually does, and does not clearly identify a verb+resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is provided. The 'Removed:' prefix implies the tool should not be used, but no alternative or context is given, leaving the agent without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure, but it only mentions deprecation. It does not describe what the tool does, its side effects, permissions, or return values. The reference to 'immutable child run' seems to describe run_prepare, not this tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and is concise, but it under-specifies the tool. It contains only a deprecation notice and a pointer to another tool, which does not earn its place as a functional description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the schema (7 parameters, an AnalysisScope type) and the lack of annotations, the description is severely inadequate. It offers no context about the tool's purpose, parameters, or behavior, leaving the agent completely uninformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about any of the 7 parameters. Since schema description coverage is 0%, the description must compensate, but it adds no parameter semantics whatsoever.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what append_dofile does; it only says it is deprecated and directs the user to run_prepare. This is misleading because the tool name suggests appending a do-file, but the description never confirms that behavior.
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 identifies the tool as deprecated and names run_prepare as the alternative, giving clear guidance not to use this tool. This effectively communicates when not to use it and which sibling to use instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral details such as effects, permissions, or error behavior. The deprecation status is the only behavioral hint, but it is not elaborated (e.g., whether the tool still functions).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise, but it is under-specified. It does not earn its place as a tool description since it omits essential purpose and parameter information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and 3 parameters, the description is missing all context needed for invocation. Since the tool is deprecated, the redirect is useful, but for any contextual understanding of the tool itself, it is completely inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about parameters like file_path, max_bytes, or project_path. The agent gets no help understanding what these parameters mean or how to use them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Deprecated: use artifact_read' does not state what the tool does. It only provides a deprecation notice and redirects to another tool, leaving the actual purpose (reading a file) implicit from the name but not described.
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 says 'Deprecated' and names the alternative 'artifact_read', giving clear when-not-to-use guidance. This is useful for an agent to avoid selecting the wrong tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as side effects, permissions, return behavior, or consequences. 'Prepare and execute a project-local run' is the entire description and gives the agent no insight into what happens when invoked.
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 a single, concise sentence with no redundancy. It is front-loaded with the deprecated warning and communicates the basic action efficiently, though this conciseness contributes to the under-specification penalized in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 7 parameters, a complex AnalysisScope schema, a non-trivial output schema, and 21 sibling tools, this one-sentence description is grossly inadequate. It provides none of the context needed for an agent to select or invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 7 parameters with 0% description coverage, and the description mentions none of them. Parameters like dofile_path, plan_scope, and timeout_seconds are left entirely undocumented, and the description makes no effort to compensate for the schema's lack of explanations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Deprecated: prepare and execute a project-local run,' which provides a verb and resource but is vague. It does not explicitly mention Stata or explain what 'prepare' means, and the deprecated flag is confusing without an alternative. It only weakly distinguishes from siblings via the deprecated label.
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 on when to use this tool or what to use instead. The 'Deprecated' label implies it should not be used, but it does not point to run_prepare/run_execute or any other alternative, leaving the agent without actionable usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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. It only mentions deprecation and gives no information about the tool's behavior, side effects, permissions, or return format. This fails to disclose any behavioral traits 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. It provides no substantive information beyond the deprecation notice, so while it is brief, it does not earn high marks for structure.
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 that the tool is deprecated, the description fully serves its purpose by warning against use and directing to artifact_read. It is complete in the context of deprecation; however, it offers no information about the tool's actual functionality or parameters, making it incomplete if the tool must be used for legacy reasons.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, and the description does not explain any of the three parameters (figure_path, max_bytes, project_path). With a complete lack of parameter documentation, the description fails to compensate, making it impossible for the agent to understand parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what the tool does; it only says 'Deprecated: use artifact_read.' It lacks a verb and resource that describe the tool's function, making it missing rather than distinct. Even the tool name 'load_figure' implies a function, but the description does not confirm or explain it.
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 instructs to use artifact_read instead, providing a clear alternative and implicitly stating when not to use this tool (never). This is the highest clarity for usage guidance, as it tells the agent exactly which tool to select.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It says nothing about what the tool does, returns, or any side effects. The deprecation notice is the only behavior mentioned, but it does not describe the tool's actual 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 a single, front-loaded sentence: 'Deprecated: use data_inspect.' It is concise and every word earns its place, clearly indicating the tool's status and providing a replacement. No wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's four parameters and an output schema, the description is severely incomplete. It fails to describe the tool's function, expected inputs, or return values. Even though deprecated, an agent could still encounter this tool and needs more context to use or avoid it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about parameters. With four parameters, including 'data_path', 'vars_list', and 'project_path', the description must compensate but does not add any meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what the tool does beyond its name, 'get_data_info'. It only says 'Deprecated: use data_inspect,' which directs users away but does not clarify the tool's function. This is not a tautology, but it fails to specify a verb and resource.
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 says 'use data_inspect,' providing a clear alternative and indicating when not to use this tool. This is direct, unambiguous usage guidance that distinguishes the tool from its replacement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 does disclose the deprecation state, which is useful, but it says nothing about what the tool does, side effects, permissions, return behavior, or why it is deprecated. For a tool that likely writes files, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, with the deprecation warning in the first words. However, the one-sentence notice is under-specified for a tool with a complex schema, sacrificing necessary behavioral and parameter context for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, nested AnalysisScope, no schema descriptions), the description is grossly incomplete. The deprecation redirect is useful, but it does not explain what the tool does, when it might still be needed, or what consequences follow from invoking it, making it insufficient for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 6 parameters with 0% description coverage, so the description must compensate. It provides absolutely no parameter information, leaving the agent without any semantic explanation for content, run_name, plan_id, plan_scope, project_path, or intent beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says only 'Deprecated: use run_prepare' and does not state what the tool does. The name 'write_dofile' suggests writing a do-file, but the description does not explicitly define the verb/resource or scope, leaving the agent to infer purpose from the name and sibling context.
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 not to use this tool by marking it 'Deprecated' and names a concrete alternative: 'use run_prepare.' This is clear when-not-to-use guidance with an explicit replacement, exceeding mere implied usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of disclosing side effects. 'Initialize' implies some creation or setup action, but the description does not state whether it creates directories, writes configuration files, overwrites existing data, or requires specific permissions. This leaves significant behavioral ambiguity.
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 a single concise sentence that front-loads the action and primary object. Every word contributes, and there is no unnecessary repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description is incomplete for an initialization tool with no annotations. It does not discuss side effects, required setup, error conditions, or how this relates to the broader project workflow. The tool may be simple, but the description still leaves key contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters. The phrase 'human-readable relative artifact path' loosely relates to artifact_dir, but project_name and project_path are completely unaddressed, and no parameter-specific meaning is added beyond the bare property names in the schema.
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 uses a specific verb ('Initialize') and resource ('one project') and adds the qualifier 'with a human-readable relative artifact path,' which gives some scope. It does not explicitly distinguish this from sibling tools like mk_dir or plan_prepare, but the core purpose is reasonably clear.
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?
The description gives no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or why project_init should be chosen over project_status, mk_dir, or write_dofile. The only implication is that it is for initializing a project, but no explicit usage context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. 'Inspect' implies a read-only operation, but it doesn't mention side effects, auth requirements, or how a null project_path is handled. This is minimal beyond what the tool name already suggests.
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 a single concise sentence, front-loaded with the verb and listing the items inspected. It is efficient and free of fluff, though it sacrifices detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and an output schema, the description doesn't clarify the tool's role within the toolset, what 'capabilities' means, or any prerequisites. It's too sparse for an agent to know when and how to use it correctly, especially with many similar sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should compensate but only vaguely references a 'selected project' without explaining the project_path parameter. The schema provides only type and default, so the description adds little meaning to the parameter.
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's purpose with a specific verb ('inspect') and resource ('project, Stata, backend, and capabilities'), which is distinct from sibling tools like run_status or data_inspect. However, it doesn't explicitly differentiate itself from those alternatives.
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?
The description provides no guidance on when to use this tool versus alternatives. There are no exclusions, prerequisites, or context about typical use cases, leaving the agent without enough information to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the tool is deprecated, but provides no information about operations, side effects, permissions, or return behavior. The deprecation status is useful but minimal.
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 a single short sentence, front-loaded with the most critical information ('Deprecated') and immediately directing to the replacement. It is appropriately sized and leaves no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the deprecation notice is clear, the description provides no information about the tool's functionality, parameters, or output. The presence of an output schema does not compensate, and the description is insufficient for an agent to effectively use this tool if needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description contains no parameter information. The three parameters (file_path, max_bytes, project_path) are entirely unexplained, so the description adds no value for understanding how to invoke the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a deprecation notice rather than a statement of what the tool does. It does not specify a verb or resource, leaving the purpose to be inferred from the tool name 'read_log'. While it points to a sibling, it does not explicitly define the tool's own function.
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 states 'Deprecated: use artifact_read,' which directly tells the agent when not to use this tool and specifies the alternative. This is clear and actionable usage guidance, fully covering the dimension.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It discloses that the operation creates or updates a draft and is 'privacy-safe,' but it does not mention side effects, idempotency, validation behavior, whether existing plans are overwritten, or how plan_id/supersedes_plan_id affect the operation. This is insufficient for a mutation tool with no annotation support.
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 a single, front-loaded sentence that efficiently communicates the core purpose. It contains no filler or redundant content, and it is appropriately sized for the limited information it provides.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the schema being rich and detailed, the tool is complex with five parameters, and the description is too minimal to provide complete guidance. It does not explain the drafting workflow, the meaning of key identifiers, or how dataset_profile is used. The presence of an output schema helps, but the description still leaves major gaps in operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description contains zero parameter guidance, and the schema description coverage is 0%. Top-level parameters like plan_id, project_path, dataset_profile, and supersedes_plan_id are not explained in the description, leaving the agent to rely on names and types alone. The description adds no value beyond the schema.
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 verb ('Create or update') and the resource ('draft analysis plan'), and the qualifier 'privacy-safe' adds useful scope. It distinguishes the tool from siblings like plan_approve, run_prepare, and write_dofile, though it does not explicitly name them.
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 for drafting or revising an analysis plan before approval or execution, but it does not provide explicit when-to-use or when-not-to-use guidance. No alternative tools are mentioned, leaving the agent to infer the workflow from sibling names and context.
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 must carry the behavioral burden. It discloses that a single read is 'bounded' and 'verified', which hints at size limits and validation behavior. However, it doesn't elaborate on failure modes, authentication requirements, or side effects, leaving gaps in transparency.
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 a single concise sentence that immediately states the tool's purpose and modes. No filler or redundant information is present, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, four parameters, and 0% schema coverage, a one-sentence description is insufficient. The output schema may cover return values, but missing usage guidance and parameter semantics leave the description incomplete for an autonomous agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no explicit meaning to the four parameters. While names like run_id and max_bytes are self-explanatory, the description doesn't clarify how they interact or which parameters apply to which mode (list vs read), failing to compensate for the schema gap.
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 uses specific verbs ('List', 'read') and identifies the resource ('run graphs') and a distinguishing trait ('bounded, verified graph payload'). It clearly indicates two operational modes (list vs. read single). However, it doesn't reference sibling tools to explicitly differentiate from similar retrieval tools like artifact_read or load_figure.
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?
The description provides no guidance on when to use graph_get versus alternatives such as artifact_read, results_get, or load_figure. The context of 'run graphs' is implied, but there are no explicit usage conditions, exclusions, or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'Freeze' suggests an irreversible state change and 'approval evidence' implies a requirement, but the description does not disclose whether the plan hash is validated, whether the plan becomes immutable, or what side effects or errors occur.
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 a single, front-loaded sentence with no filler words. It efficiently communicates the core action and object without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five parameters, no annotations, and zero schema descriptions, the description is too sparse. It does not explain prerequisites, the meaning of the expected SHA-256, or how this tool fits into the overall workflow, though an output schema may cover return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only loosely maps 'approval evidence' to approval_statement. It does not explain plan_id, expected_plan_sha256, approved_by, or project_path, leaving most parameters semantically unsupported.
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 the specific verb 'freeze' with the resource 'ready analysis plan' and the qualifier 'explicit approval evidence,' which clearly differentiates it from sibling tools like plan_prepare. This is a concise and unambiguous statement of what the tool does.
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?
The description provides no explicit guidance on when to use this tool versus alternatives such as plan_prepare or run_execute. The word 'ready' implies a prerequisite but does not state a clear workflow context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure, but it only states 'request cancellation' without mentioning consequences, permissions, reversibility, or what happens to the run. This is insufficient for a mutating 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 a single, front-loaded sentence with no redundant information. It is concise and immediately communicates the tool's core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having three parameters and an output schema, the description is too terse to provide adequate context for correct invocation. It lacks information about accepted action values, how to obtain run_id, and the semantics of project_path, making the tool under-specified for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of the parameters 'action', 'run_id', or 'project_path'. The description adds no meaning beyond the schema field names, which are ambiguous (especially 'action').
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 'Request cancellation of one active background run' uses a specific verb and resource, making the tool's purpose immediately clear. It distinguishes itself from sibling tools like run_execute and run_status by focusing on cancellation.
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 when one wants to cancel an active background run, but it does not explicitly state when to use this tool versus alternatives. No exclusions or alternative tool mentions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden of behavioral disclosure. It only states 'Read', which implies non-mutating behavior, but does not disclose any permissions, error handling, potential cost, or what 'durable lifecycle state' means. This is minimal transparency beyond the tool's name.
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 a single sentence, front-loaded with 'Read', and contains no superfluous words. It is appropriately sized for a simple read operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the output schema likely covers return values, the description lacks workflow context. It does not explain where 'durable lifecycle state' or 'provenance paths' come from, and it lacks usage alternatives. For a tool with no annotations and a 0% schema description coverage, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must clarify parameters. It implies run_id identifies the run via 'for one run', but does not explain project_path at all. No additional meaning is provided for either parameter beyond what the schema already shows.
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 tool reads durable lifecycle state and provenance paths for a single run. The verb 'read' and resource 'run' distinguish it from sibling tools like run_execute or run_control, and from project_status which targets projects.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention how it relates to run_prepare, run_execute, project_status, or other siblings, nor does it indicate whether it should be used after a run completes or during execution.
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?
The description adds the behavioral detail that it accesses a licensed local Stata installation, but does not disclose failure modes, prerequisites beyond the license, or side effects. Since no annotations exist, more detail would be expected.
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 one short sentence that directly states the purpose without filler. It is efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple and has an output schema, the description omits parameter context and usage scenarios relative to sibling tools. The lack of any mention of project_path or when to invoke this tool makes it incomplete for an agent to use with confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema includes two parameters with zero description coverage, and the description provides no information about 'command' or 'project_path' beyond the names themselves. The description does not compensate for the schema's lack of 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 clearly states the tool retrieves Stata command documentation, specifying both the resource and the method (licensed local Stata). This distinguishes it from the generic 'help' sibling tool.
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 provided on when to use this tool versus alternatives like 'help' or when the local Stata license is required. The description simply states the action without usage context.
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?
No annotations exist, so the description carries the burden. 'Inspect' strongly implies a read-only operation, and 'bounded previews' hints at a limitation, but details like permission requirements, exact preview bounds, and whether data is modified are not disclosed. It provides minimal but non-contradictory 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?
A single sentence that starts with the action verb and lists the scope efficiently. Every word earns its place, with no repetition or filler. It is appropriately sized given the tool's straightforward purpose.
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?
An output schema exists, so return values are covered structurally. However, parameter semantics and usage guidelines are absent, and the description is too terse to compensate for the lack of annotations and 0% schema coverage. It meets the minimum for a simple inspection tool but leaves notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the four parameters (data_path, variables, preview_rows, project_path). It lists high-level capabilities but fails to map them to parameters, leaving the agent without necessary guidance for correct invocation.
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?
Uses a specific verb 'Inspect' with a clear resource and enumerated scope (metadata, missingness, labels, bounded previews). This makes the basic purpose evident, but it does not explicitly differentiate from the sibling tool get_data_info, so it falls short of a 5.
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 when to use it (when you need dataset inspection), but it provides no explicit guidance on when not to use it or how it compares to alternatives like get_data_info. There are no exclusions or alternative tool references.
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, the description carries the full burden. It discloses the tool is deprecated, which is a significant behavioral trait, but it does not describe what happens on invocation, output, or side effects. Still, the deprecation warning is valuable.
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 a single, front-loaded sentence with no wasted words. It communicates the essential redirect immediately.
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 the deprecation and the clear pointer to `stata_help`, the description is sufficient to route the agent away from this tool. It does not explain parameters or return values, but for a deprecated tool, the recommended action is to avoid it, so the context is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 2 parameters with no descriptions, and the description offers no parameter guidance whatsoever. The agent cannot infer the meaning of `command` or `project_path`.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what the tool does; it only provides a deprecation notice and points to an alternative. It lacks a verb and resource, and while it distinguishes from siblings by naming stata_help, it doesn't explain its own purpose.
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 says 'Deprecated: use stata_help,' clearly telling the agent when not to use this tool (always) and which alternative to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only reveals that execution can be synchronous or in the background, but omits side effects (e.g., running code, producing outputs), resource consumption, error conditions, or whether it is a read-only or mutating operation. The agent cannot anticipate the impact of executing a run.
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 a single, front-loaded sentence with no fluff. Every word contributes to conveying the core action and the two execution modes. It is exemplary in conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, an output schema, and no annotations, the one-sentence description is insufficient. It does not explain the expected workflow (e.g., that run_prepare must precede it), the purpose of optional parameters, or any caveats. The output schema mitigates the need to describe return values, but the overall context remains incomplete for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It indirectly explains 'background' via 'synchronously or in the background' and 'run_id' via 'one prepared run', but provides no meaning for 'project_path' or 'timeout_seconds'. The description adds minimal value over the raw schema, leaving most parameters unexplained.
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 ('execute') and a specific resource ('one prepared run'), which clearly distinguishes it from siblings like run_prepare (prepares a run), run_status (checks status), and run_control (controls a run). It also mentions the two modes (synchronous or background), which adds functional clarity.
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 the tool is used after a run has been prepared, but it does not explicitly state when to use it vs alternatives or mention prerequisites. There is no exclusionary guidance (e.g., 'use run_status to check before executing') or advice on when to choose synchronous vs background execution. The usage context is 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It indicates the tool returns typed structured results but does not mention error handling, prerequisites (e.g., run must be finalized), or any side effects. This is minimal for a tool that retrieves data.
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 a single, front-loaded sentence with no filler. Every word contributes to the core purpose, making it appropriately sized and easy to parse.
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?
While the tool has an output schema that may document return values, the description is too thin to fully orient an agent among many sibling tools. It lacks guidance on when this tool is preferred (e.g., after run completion) and does not clarify parameters or edge cases. It is minimally adequate but not comprehensive.
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 2 parameters with 0% description coverage in the schema, and the tool description does not explain run_id or project_path. run_id is somewhat inferable from the tool name, but project_path's purpose is unclear. The description adds no semantic value beyond what the parameter names alone suggest.
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 ('Return') and resource ('typed structured results') with a clear scope ('bound to one finalized run'). This distinguishes it from sibling tools like run_status or data_inspect, which focus on run state or raw data inspection.
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 phrase 'bound to one finalized run' implies this tool is appropriate after a run finishes, but it does not explicitly state when to use it over alternatives or what conditions are required. No exclusions or alternative tool references are provided.
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, the description must carry the burden of transparency. It discloses that the artifact is 'bounded' (likely by max_bytes) and supports text or image types. It does not explain behavior on exceeding the bound, authentication needs, or return structure, but the output schema partially covers returns. This is adequate but not rich.
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 a single, front-loaded sentence that conveys the core purpose, scope, and type constraints with no wasted words. It is appropriately concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is too sparse given four parameters with no property-level descriptions. It fails to explain parameter roles, defaults, or how this tool differs from sibling read tools. The 'bounded' and 'run' context is helpful but leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not mention run_id, relative_path, max_bytes, or project_path explicitly. 'Bounded' hints at max_bytes and 'belonging to a run' hints at run_id, but this is insufficient semantic enrichment for four parameters.
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 'Read one bounded text or image artifact belonging to a run' clearly states the verb (read), resource (artifact), scope (run), and type constraints. This distinguishes it from generic siblings like read_file or read_log.
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 phrase 'belonging to a run' implies this tool is specifically for run artifacts, giving some context. However, it does not explicitly state when to use this tool over alternatives like read_file or load_figure, nor does it mention any exclusions or limitations.
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, the description carries the burden. It discloses two notable behaviors: the run is immutable and not executed. Yet it omits other aspects like side effects, permissions, prerequisites, or return values, which are important for a create 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 a single, well-formed sentence. It is front-loaded with the action and contains zero redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters, a nested AnalysisScope object, and no annotations, this description is minimal. It does not explain how a run relates to plans, dofiles, or the overall workflow, and while an output schema exists, it does not substitute for behavioral 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?
Schema description coverage is 0%, and the description does not explain the parameters. The only hint is 'descriptively named', which relates to run_name, but the core required parameters (dofile_content, intent) are left entirely unexplained.
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 tool's function: creating a run without executing it. The verb 'Create' and resource 'run' are specific, and the qualifier 'without executing it' distinguishes it from sibling run_execute.
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 phrase 'without executing it' provides clear context that this tool is for preparation rather than execution, implying when to use it. However, it does not explicitly name alternatives or state when not to use it, 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.

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:

[![STATA-MCP-AGENT MCP server](https://glama.ai/mcp/servers/taewat07/STATA-MCP-AGENT/badges/card.svg)](https://glama.ai/mcp/servers/taewat07/STATA-MCP-AGENT)

Score Badge

Copy to your README.md:

[![STATA-MCP-AGENT MCP server](https://glama.ai/mcp/servers/taewat07/STATA-MCP-AGENT/badges/score.svg)](https://glama.ai/mcp/servers/taewat07/STATA-MCP-AGENT)

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/taewat07/STATA-MCP-AGENT'

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