Skip to main content
Glama
Sign In

Comunicate.top

by top.comunicate
OverviewDiscussionsAdmin

Comenzile de redactare

list_writing_orders
Read-onlyIdempotent

Starea comenzilor de redactare și articolele livrate.

Use when the user asks about articles they ordered to be written. Do not use for publications: use list_publications.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_writing_orders"
  }
}

Input Schema

NameRequiredDescriptionDefault
statusNoDoar comenzile în starea dată: NOUA, IN_LUCRU, LIVRATA, REFUZATA, ANULATA sau ESUATA.

Output Schema

NameRequiredDescriptionDefault
itemsNoarray of {id, status, articleId}. Writing orders of the organisation.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "additionalProperties": {},
+  "properties": {
+    "items": {
+      "description": "array of {id, status, articleId}. Writing orders of the organisation."
+    }
+  },
+  "type": "object"
+}
  2. Changed1 schema field changed
    • addedInput schema / properties / status / description
      Added value: +"Doar comenzile în starea dată: NOUA, IN_LUCRU, LIVRATA, REFUZATA, ANULATA sau ESUATA."
  3. Changed1 schema field changed
    • removedInput schema / additionalProperties
      Removed value: -false
  4. First observed

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety and idempotency profile is fully covered without the description. The description adds only a hint about returned content ('articolele livrate'); it says nothing about ordering, pagination, or volume of results. Given a rich annotation set and an output schema, this is adequate but not additive.

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 text is short and the guidance is front-loaded, but the opening Romanian fragment largely restates the tool title and mixes languages with the English instructions, adding noise before the actionable sentence. Two sentences with one of them partly redundant keeps this at adequate rather than efficient.

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 filtered-list tool with one optional parameter, full schema coverage, an output schema and complete read-only annotations, the description supplies the routing information an agent needs. The only gap is behavior when 'status' is omitted (all orders vs. default state), which is minor given the structured fields already available.

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

Parameters3/5

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

Schema description coverage is 100% and the single optional 'status' parameter already documents the accepted states (NOUA, IN_LUCRU, LIVRATA, REFUZATA, ANULATA, ESUATA). The description adds no meaning about the parameter, such as default behavior when status is omitted. Baseline 3 applies when the schema does the heavy lifting.

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 English sentence makes the resource unambiguous: articles the user ordered to be written, plus it names the sibling it is not (list_publications). The leading Romanian sentence is a noun fragment ('Starea comenzilor de redactare și articolele livrate') rather than a verb+resource statement, so an agent must read past it to get the actual purpose, but the combined text is still clearly distinguishable from sibling 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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states both the positive trigger ('Use when the user asks about articles they ordered to be written') and the exclusion with a named alternative ('Do not use for publications: use list_publications'). This is the explicit when/when-not/alternative pattern, leaving nothing to inference.

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

All Comunicate.top toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources