olivetin-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation3/5
The core OliveTin tools are mostly distinct, but the inclusion of unrelated tools (brave_search, render_diagram, render_chart) creates confusion about the server's purpose and could lead to misselection. There is also mild overlap between get_execution_logs and get_execution_status, though descriptions help clarify.
Naming Consistency4/5
Most tools follow a clear verb_noun snake_case pattern (e.g., list_olivetin_actions, get_execution_status, kill_action). Minor exceptions like whoami, readyz, and brave_search deviate from the pattern but are still recognizable and don't cause significant inconsistency.
Tool Count3/5
At 18 tools, the set is on the heavier side. The 15 OliveTin-specific tools are reasonably scoped for the domain, but the three unrelated utility tools pad the count and make the server feel less focused.
Completeness4/5
The OliveTin surface covers the core lifecycle: listing/getting actions, starting/killing/restarting, status/logs, approvals, entities, validation, user/server info, health, and reload. Minor gaps include lack of entity mutations and synchronous action start, but these are not critical for typical workflows.
Average 4.3/5 across 18 of 18 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 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 failing
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already indicates a read-only operation; the description reinforces this and adds the extra behavioral detail 'No approval needed', which goes beyond the annotation. It also names the RPC and lists allowed input types, but does not mention error behavior or the return format.
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 front-load the action and include the essential type list. Every sentence adds value with no redundancy or filler.
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-value details are not needed. However, with four parameters and no schema descriptions, the description leaves 'binding_id' and 'argument_name' underspecified, making it incomplete for a fully informed invocation. It covers the core purpose but not all parameter semantics.
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 partially does by enumerating valid values for 'type', but it does not explain the purpose of 'binding_id' or 'argument_name'. The meaning of 'value' is implied but not clarified. This leaves half the parameters underspecified.
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 function: 'Validate an argument value against an OliveTin argument type' (specific verb + resource) and enumerates the supported types. It is unambiguous but does not explicitly differentiate from sibling tools such as start_action_async or list_olivetin_actions.
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?
Provides a useful usage trait: 'No approval needed — read-only.' However, it lacks explicit when-to-use guidance or mention of alternatives. The context that this is a validation RPC implies when it would be used, but no exclusions or preferred scenarios are stated.
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?
The description directly contradicts the annotation readOnlyHint=true. Killing an action is a state-changing operation, not read-only. The description attempts to reframe it as a safety stop, but it still modifies execution state, so this is a serious inconsistency.
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 three focused sentences, front-loaded with the action, and contains no unnecessary information. Every sentence adds value regarding either the precondition, outcome, or safety posture.
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 core behavior, precondition, return statuses, and clarifies safety. However, it does not explain how to obtain the execution_tracking_id, and the annotation contradiction creates ambiguity. The presence of an output schema partially offsets the need to describe return values in detail.
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 single parameter execution_tracking_id is explained in the description as the identifier used to kill the action. It also adds context about the action needing to be running and references the can_kill field, which compensates 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 clearly states the tool's purpose: "Kill a currently running OliveTin action by its execution_tracking_id." It uses a specific verb ("kill"), identifies the resource ("currently running OliveTin action"), and distinguishes it from sibling tools like restart_action or get_execution_status.
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 a clear precondition: "Only works when the LogEntry's can_kill field is true." It also explains the outcome statuses, but it doesn't explicitly mention alternatives or exclusions relative to sibling tools, so it stops short of a full guidance score.
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 readOnlyHint: true, the description adds context beyond the annotation by clarifying that no approval is needed and enumerating the returned proto fields. This gives the agent useful behavioral and data-level information without contradicting the annotation.
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 front-loaded with the primary action and resource. The additional details about proto fields and approval status are useful and concise, with no extraneous wording.
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 tool has an output schema and readOnly annotation, so the description need not explain return structure. It covers the main purpose and added context, but it misses parameter semantics, which would make it fully complete for a tool with two parameters and zero schema descriptions.
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, but it does not explain the purpose of action_id or page_size. The parameter names are self-explanatory to some degree, but the description lists only output fields, leaving input parameters ambiguous.
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' and the resource 'OliveTin execution history (LogEntry records)', which is specific and unambiguous. It differentiates from siblings like get_execution_status and list_olivetin_actions by naming the domain as execution history.
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 use for retrieving execution history but does not explicitly state when to use this over alternatives, nor any exclusions or prerequisites. 'No approval needed' provides an authorization note but does not offer comparative usage guidance.
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?
The annotation already declares readOnlyHint=true, so the description's 'read-only' is redundant. However, adding 'No approval needed' gives extra behavioral context beyond the annotation, which is useful. The phrase 'Init RPC' also hints at technical 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 a single, front-loaded sentence that conveys purpose, approval requirements, and read-only nature without any unnecessary words.
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 getter with no parameters and an existing output schema, the description is complete. It covers what the tool returns, its read-only nature, and the fact that approval is not needed.
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, and the input schema is empty. Baseline for no parameters is 4, and the description does not need to elaborate on parameter details since there are none.
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 OliveTin server info and version, with a specific verb and resource. It distinguishes itself from siblings that perform actions like restart or kill, though it doesn't explicitly name 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?
The description implies this is a simple read-only getter and highlights that no approval is needed, but it does not explicitly state when to prefer this tool over others or provide exclusion criteria.
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?
Annotations already declare readOnlyHint=true, but the description adds that 'No approval needed', which is a useful behavioral trait beyond the annotation. It reinforces read-only behavior and mentions the RPC, providing extra context without contradicting the 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 a single, front-loaded sentence with no unnecessary words. It efficiently conveys the action, target, parameters, and safety profile in one line.
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 tool is simple and has an output schema, so return values are covered. The description covers the essential invocation details (unique key, type, read-only). It doesn't explain what an OliveTin entity is, but given the output schema and annotations, the information is sufficient for a basic understanding.
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, but it only restates the parameter names ('by unique key and type') without explaining their meaning, constraints, or the empty default for type. Minimal value is added over 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 clearly states the tool fetches a single OliveTin entity by unique key and type, using a specific verb (Fetch) and resource. It distinguishes from the sibling get_entities by explicitly saying 'single', and references the GetEntity RPC for precision.
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 implies usage for single-entity lookup and mentions that no approval is needed, giving clear context. However, it doesn't explicitly contrast with the 'get_entities' sibling or other alternatives, so it lacks an explicit exclusion, but the context is clear enough for an 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?
Annotations declare readOnlyHint=true, and the description reinforces this with 'read-only' and adds 'No approval needed'. It also discloses the return contents (full Action proto with arguments, icon, timeout, ACL fields), which is useful behavioral context beyond the annotation.
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 sentences, front-loaded with the core action and resource, then a concise mention of return details. Every sentence earns its place with no fluff.
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 read tool with one parameter and an output schema, the description covers the essential context: it fetches a single binding, lists return fields, and notes no approval is needed. The output schema handles return structure details.
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% for the single parameter binding_id. The description only says 'by ID', which adds no meaning beyond the parameter name. It does not explain where to find the ID or any format constraints, so it fails to compensate for the lack of schema description.
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 ('Fetch') and resource ('OliveTin action binding') with scoping by ID. It clearly distinguishes from sibling tools like list_olivetin_actions by indicating it fetches a single binding. The mention of the RPC name and return type reinforces the purpose.
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 implies when to use: when a single action binding is needed by its ID. It does not explicitly name alternatives or exclusions, but the context is clear. Since it doesn't explicitly say 'use this instead of list_olivetin_actions', it lacks an explicit exclusions statement, aligning with a score of 4.
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?
Annotations already state readOnlyHint=true. The description adds behavioral details beyond that: it returns a /tmp path, uses an external service (quickchart.io), and explicitly states no approval is needed, which are useful for the agent.
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 sentences, front-loaded with the core action, and contains no unnecessary words. Every sentence adds value.
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 rendering tool, the description provides the essential context: purpose, required input type (Chart.js config), the external service, and the output path. It also mentions approval state. Output schema exists, so return values are covered elsewhere.
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 coverage is 0%, so the description must compensate. It explains that config is a Chart.js config, giving meaning to the required parameter. Width, height, and background_color are self-explanatory from names and defaults but not described in detail.
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 'Render' and identifies the resource 'Chart.js config' and result 'PNG via quickchart.io', clearly distinguishing it from sibling render_diagram. It also states the output as a return path.
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: it is for rendering Chart.js configs. 'No approval needed' gives a usage guideline about invoking without approval. However, it does not explicitly mention alternatives or exclusions.
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?
Annotations already indicate destructive behavior (destructiveHint: true). The description adds useful context: approval requirement and that it re-runs with the same arguments as the original execution, which provides caution beyond the raw 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?
Two concise sentences, front-loaded with the action and includes the essential caveat. No wasted words.
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 core functionality, the approval requirement, and the re-run semantics, which is adequate for a simple one-parameter tool. It omits details like return format, but with an output schema present, those are not strictly necessary.
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?
The only parameter, execution_tracking_id, is referenced in the description, tying it to the action being restarted. However, it does not explain how to obtain the ID or its format, leaving some ambiguity despite the low 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 clearly states the verb and resource: 'Restart a previously executed OliveTin action by its execution_tracking_id.' It distinguishes from siblings like start_action_async (new execution) and kill_action by focusing on re-running an existing execution.
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 on when to use (for re-running a previously executed action) and the key caveat that human approval is required and it re-triggers a real action. However, it does not explicitly name alternatives or state when not to use.
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?
The description adds context beyond the readOnlyHint annotation by mentioning 'No approval needed' and the return format (top results with title, URL, description). This provides useful behavioral details about the tool's safety profile and expected output, without contradicting the annotation.
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 concise and front-loaded, stating the purpose in the first phrase. Every sentence adds value: the API source, the return fields, and the approval/read-only status. No unnecessary words.
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 2-parameter tool with an output schema present, the description is complete. It clarifies the tool's purpose, output shape, and approval requirements. There is no missing critical context that would hinder an agent from using the tool correctly.
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?
The schema has no parameter descriptions (0% coverage), so the description must compensate. The description implies that 'query' is the search string and 'count' limits the number of top results, but it does not explicitly define these parameters. The parameter names are self-explanatory enough for basic use, but the description could add more explicit semantics.
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: 'Search the web using the Brave Search API.' It specifies the resource (web via Brave), the action (search), and the return format (top results with title, URL, and description). This distinguishes it from the unrelated sibling tools, which focus on server management and execution.
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: whenever a web search is needed. It also states 'No approval needed — read-only,' which serves as a guideline for invoking it without approval workflows. While it does not explicitly name alternatives or exclusions, the sibling tools are unrelated, so the context is sufficient.
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 annotations already indicating destructive intent, the description adds valuable context: 'Requires human approval — this triggers a real action on the host.' It also discloses the async return behavior (execution_tracking_id immediately) without contradicting the annotations, enhancing the agent's understanding of side effects and process.
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?
Three sentences, each earning its place: purpose, async behavior with follow-up tools, and approval requirement. The description is front-loaded with the core action and avoids repetition or fluff.
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 two simple parameters and an output schema, the description covers all essential aspects: what it does, how it behaves, what to do next, and the human approval prerequisite. It is sufficiently complete without needing to explain return values (output schema exists).
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%, placing the burden on the description to explain parameters. The description mentions 'arguments' only in the tool name, not in the description, and fails to explain what arguments are or how they map to the action. The schema shows action_id and arguments but provides no semantic meaning beyond types, leaving a significant 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 clearly states the tool's purpose: 'Start an OliveTin action asynchronously (StartAction RPC).' It distinguishes from sibling tools by emphasizing async behavior and the immediate return of an execution_tracking_id, which differentiates it from status, cancel, and list 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 directs users to get_execution_status for polling and kill_action for cancellation, providing clear alternative actions. It also notes the requirement of human approval, implying when this tool is appropriate. However, it does not explicitly state when not to use it (e.g., if synchronous results are needed), so it stops short of full when/when-not guidance.
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?
Annotations already declare readOnlyHint, so the 'read-only' phrase is redundant, but the description adds 'No approval needed' and explains what entities represent (monitored services/hosts), providing context beyond the annotation.
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 with the key action front-loaded. No unnecessary words; every element contributes to understanding.
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 simplicity (no params, output schema present, no nested objects), the description fully covers purpose, safety, and semantics. It is complete for an agent to invoke correctly.
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?
With zero parameters, schema coverage is trivially 100%. The description adds no parameter details because none exist. Baseline 4 is appropriate for a no-parameter tool.
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 'List' with a clear resource 'OliveTin entities' and differentiates from the singular sibling 'get_entity' by noting it lists all entities. The RPC name adds precision.
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 clearly states this is a read-only operation requiring no approval, which helps an agent choose it for safe listing tasks. It does not explicitly mention alternatives like 'get_entity' for single entities, but the plural 'all' implies the scope.
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?
Annotations already declare readOnlyHint=true. Description adds relevant context that no approval is needed, which is not captured by annotations. No contradiction.
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 concise sentence that conveys purpose and key usage context without unnecessary words.
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 1-parameter read-only tool with an output schema, the description covers the core actions, parameter source, and approval requirement. Nothing critical 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%, but description explains the parameter's origin (returned by StartAction), providing meaning beyond the raw schema definition of a string.
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 the specific verb 'Check' and resource 'status of a running OliveTin action', with clear reference to execution_tracking_id. This distinguishes it from siblings like get_execution_logs and kill_action.
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?
Implies usage for checking status when an execution_tracking_id is available from StartAction, and notes 'No approval needed.' Lacks explicit exclusion of alternatives, but context is clear given sibling names.
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?
Annotations only include readOnlyHint=true, but the description adds value by disclosing the output content (IDs, titles, argument schemas, approval flags) and explicitly stating 'No approval needed' for the call itself. This goes beyond the read-only hint and gives the agent confidence about side-effect-free behavior and operational prerequisites.
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 concise, consisting of two short sentences. It front-loads the core purpose ('List all available OliveTin actions') and packs useful specifics (what fields are returned, no approval needed) without any filler or repetition. Every sentence earns its place.
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's simplicity (no parameters, read-only, no side effects), the description covers all essential information: the action scope ('all'), the list of returned fields, and the absence of an approval requirement. An output schema exists, so return value details need not be repeated. This is complete for an agent to use correctly.
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 and an empty input schema, so the schema description coverage is trivially 100%. The baseline for zero parameters is 4, and the description does not introduce any parameter-related confusion. It appropriately focuses on the output rather than nonexistent 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?
The description clearly states the tool lists all OliveTin actions and specifies the exact information returned (IDs, titles, argument schemas, approval requirements). The verb 'list' is specific, the resource 'OliveTin actions' is unambiguous, and it distinguishes itself from sibling tools like list_pending_approvals.
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 this tool: to discover available actions and their properties. It does not explicitly exclude alternatives or name them, but the purpose is self-evident and the added note 'No approval needed' signals that this operation is safe and callable without restrictions. This is clear context without explicit exclusions.
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?
The annotation readOnlyHint:true already indicates safety, but the description reinforces this with 'No approval needed — read-only' and adds useful behavioral detail about the output: each entry includes the approval URL. This goes beyond the annotation by clarifying exactly what data is returned.
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 sentences, front-loaded with the core purpose, then a usage note and safety clarification. Every sentence adds value with no redundancy or fluff.
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 fully covers what the tool lists, what information it provides (approval URL), when to call it, and its read-only nature. With an output schema present and no parameters, nothing important is missing for this simple tool.
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, and the schema is an empty object. The baseline for 0 params is 4, and no parameter explanation is needed. The description does not attempt to add param semantics, which is appropriate.
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 purpose: 'List all OliveTin actions currently waiting for human approval, with the URL the human must visit to approve or deny.' It uses a specific verb and resource, and the focus on 'pending approvals' distinguishes it from the sibling tool 'list_olivetin_actions'.
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 explicit usage context: 'Call this after triggering a destructive action to get the approval link.' This tells the agent when to use the tool, though it does not mention alternatives or exclusions. The 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true; the description adds beyond that by mentioning 'No approval needed' and specific response behavior ('Returns 200/ready'), giving useful context about authentication and success criteria.
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, compact sentence that front-loads the purpose and includes essential safety details without waste.
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 zero-parameter health check, the description fully covers purpose, output, and safety context. The empty input schema and existing output schema (though not detailed) make this complete.
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 the baseline is 4. The description adds nothing about parameters, but none are needed; it correctly focuses on behavior.
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 and resource: 'OliveTin readiness probe (GetReadyz RPC)'. It clearly indicates the tool checks OliveTin health and returns 200/ready, distinguishing it from sibling tools like get_server_info or get_execution_status.
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?
Provides clear context for when to use it (readiness check) and adds 'No approval needed — read-only' as a practical usage hint. It does not explicitly contrast with alternatives, so it misses the top score but is still clear.
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?
Annotations include readOnlyHint=true, and the description adds behavioral context by noting 'No approval needed — read-only' and indicating that it forces an immediate refresh. This goes beyond the annotation without contradicting it, though it could be more detailed about side effects or response 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 three concise sentences, each serving a distinct purpose: stating the core action, providing usage timing, and noting safety/read-only nature. Every sentence earns its place with no redundant 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?
With zero parameters and an output schema provided, the description fully covers what an agent needs to know: the tool's function, when to use it, and its non-destructive nature. It is complete for this simple tool.
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 to document beyond the schema. Per the baseline, 0 params earns a 4; the description appropriately focuses on the action rather than parameter semantics.
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 with a specific verb ('Force an immediate refresh') and identifies the resource ('OliveTin action catalog from GetDashboard'). It distinguishes itself from sibling tools like list_olivetin_actions, making its purpose 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?
Provides explicit when-to-use guidance: 'Use this after adding, removing, or editing actions in OliveTin config without waiting for the automatic refresh interval.' This gives clear context but does not mention alternatives or when not to use it, so it falls slightly 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?
Annotations provide readOnlyHint=true, but the description adds valuable behavioral context beyond that: it relies on the external mermaid.ink service, returns a /tmp path, and explicitly states no approval is needed. This is consistent with the annotations and adds operational clarity.
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?
Three short sentences, each carrying essential information: the action and target, the output location, and the approval requirement. There is no wasted wording 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 one-parameter tool with a read-only annotation, the description covers what the tool does, how it operates (via mermaid.ink), where the output goes (/tmp path), and whether approval is needed. No critical information is missing for invoking it correctly.
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?
While the schema only defines a single 'spec' string with no description, the tool description compensates by identifying it as a 'Mermaid diagram spec'. This gives the parameter meaning beyond the bare schema and is sufficient for a single-parameter tool, though no examples or constraints are provided.
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 ('Render') and resource ('Mermaid diagram spec as PNG via mermaid.ink'), clearly distinguishing it from sibling tools like render_chart. It also states the output location ('/tmp path'), making the tool's purpose 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 clearly implies when to use the tool (when a Mermaid diagram spec needs to be rendered as PNG) and adds an operational note ('No approval needed'). It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to select this tool over siblings.
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?
Annotations already declare readOnlyHint=true, and the description reinforces this by stating 'read-only'. It adds valuable context beyond annotations: 'No approval needed' informs the agent that this operation is safe and unauthenticated in terms of approvals, reducing hesitation. The mention of 'WhoAmI RPC' also provides protocol 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 a single, compact sentence that conveys all essential information immediately. It is front-loaded with the core action and resource, with safety context appended. Every word earns its place with no 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?
Given the tool's simplicity, an empty schema, and an output schema being present, the description is complete. It states the tool's purpose, safety profile, and protocol context. It doesn't need to explain return values because the output schema covers that.
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 and the input schema is an empty object, so there is nothing to explain. According to the instructions, a baseline of 4 is appropriate for no-parameter tools. The description adds no parameter information because none is needed.
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 returns information about the current authenticated OliveTin user, using a specific verb and resource. It uniquely identifies this as a WhoAmI RPC, distinguishing it from all sibling tools which have different purposes.
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 context for when to use this tool is clear: whenever information about the current authenticated user is needed. It doesn't explicitly mention alternatives or exclusions, but the tool is self-contained and no alternative is relevant, so no additional guidance is required.
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:

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

Score Badge

Copy to your README.md:

[![olivetin-mcp MCP server](https://glama.ai/mcp/servers/vaddisrinivas/olivetin-mcp/badges/score.svg)](https://glama.ai/mcp/servers/vaddisrinivas/olivetin-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/vaddisrinivas/olivetin-mcp'

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