ARCO MCP

by isaacwars

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.4.0
Disambiguation5/5
Each tool targets a distinct aspect of the ARCO workflow, from case processing and validation to specific audits (draft, argumentation, identity, source) and graph-based legal research. Even similar-sounding audit tools are clearly differentiated by their input types and focus areas, eliminating ambiguity.
Naming Consistency4/5
Tool names are consistently snake_case and mostly follow a verb_noun pattern (e.g., process_case, validate_case, audit_draft), but several are noun phrases (deadline_timeline, law_articles, legal_graph) or standalone nouns (health). Despite the deviation, the naming style is uniform and readable.
Tool Count3/5
With 18 tools, the server sits in the heavier range (16-25) per the rubric. The count is justified by the dual focus on drafting workflow and legal graph research, but it feels slightly heavy for a single-purpose server.
Completeness5/5
The tool set covers the full ARCO lifecycle: validation, assessment, drafting, auditing, legal basis selection, timeline calculation, and escalation. The inclusion of a legal graph with semantic search and community details ensures no obvious gaps in legal research or case analysis.
Average 3.4/5 across 18 of 18 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions the 'without over-citing' constraint, but it does not indicate whether the tool is read-only, what return format to expect, or any side effects. This leaves significant ambiguity for a tool that presumably analyzes case 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, concise sentence that is easy to parse and front-loaded with the action verb. There is no redundancy or unnecessary content, making it highly efficient for its length.
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 that the tool has one parameter, no output schema, and no annotations, the description is grossly incomplete. It fails to explain the input format, expected behavior, or return value, making it inadequate for an agent to confidently select and invoke the 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 single parameter 'case_json' has no schema description (0% coverage), and the tool description does not mention it at all. The description fails to explain what 'case_json' should contain or how it should be structured, leaving the agent without sufficient information to construct a valid request.
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: selecting applicable articles based on rights and facts, with the added constraint of avoiding over-citation. It is specific about the verb and resource, though it does not explicitly differentiate from sibling tools like 'law_articles' or 'escalation_basis'.
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?
There is no guidance on when to use this tool versus alternatives. The description only states what it does, not the context in which it should be invoked or any conditions that would favor it over sibling tools.
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 burden. It states a return value but doesn't explain what 'controlled matrix' means, whether it filters by article numbers, or any error behavior. The absence of any behavioral detail beyond the return type makes it insufficient for understanding side effects or data handling.
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 short sentence, extremely concise with no redundancy. However, the brevity comes at the cost of clarity, as the phrase 'controlled matrix' is not elaborated. It scores moderately because it is efficiently worded but under-specifies the tool's behavior.
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?
With no output schema and no annotations, the description should provide more context about what the matrix contains and how to interact with the tool. It also doesn't mention the parameter or any use cases. For a tool that appears to fetch legal articles, this is inadequate to guide an agent effectively.
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 single parameter `article_numbers_json` is not mentioned in the description. Schema coverage is 0%, and the description fails to compensate by explaining how the parameter influences the result. The tool name and description give no hint that the parameter likely specifies a list of article numbers.
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 states it returns a controlled matrix of articles from LFPDPPP 2025, which identifies the tool's function and the specific legal corpus. The term 'controlled matrix' is somewhat vague, but the verb and resource are clear enough to distinguish it from sibling tools focused on case processing.
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 usage guidance is provided. The description doesn't mention when to prefer this tool over others or any prerequisites, leaving the agent without criteria for selection.
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. It discloses the output structure (map components) but omits behavioral details such as input format, error conditions, side effects, or return type handling. This is minimal disclosure for a tool without 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 sentence that efficiently conveys the tool's purpose and output components. It avoids filler and front-loads the key verb, making it appropriately sized.
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 description lists the map's components, it fails to explain the input contract (case_json format), usage context, or return structure. Given the tool has no output schema and one undocumented parameter, this leaves significant gaps for the 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?
The schema has one parameter, case_json, with no description and 0% schema coverage. The tool description does not mention case_json or explain what data it should contain, leaving the agent without guidance on how to populate this required field.
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 builds an argument-by-argument map and enumerates its components (fundamento, alcance, limite legal, prueba requerida, controles de rechazo). This specific verb+resource makes the purpose clear, though it does not explicitly distinguish from sibling tools like audit_argumentation or legal_graph.
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 such as audit_argumentation or legal_graph. The description only states what it does, leaving the agent to infer usage from context.
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 supplied, and the description does not disclose behavioral traits such as whether this is a read-only operation, any required permissions, or the return format. It only states the content of the output, which is insufficient for the agent to anticipate tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is concise and front-loads the main action ('Detalle completo'), though it could have used the brevity to add more practical details without becoming verbose.
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?
With one parameter, no output schema, and no annotations, the description is far from complete. It does not clarify what constitutes a 'community' in the legal graph, how to invoke the tool correctly, or what the response structure looks like, leaving significant gaps for the 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?
The schema has one parameter 'community_id' with 0% description coverage. The description never mentions how to specify the community, its format, or whether it is required. The tool name and phrase 'de una comunidad' imply the parameter's role, but the description fails to add meaningful semantic 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 tool provides a complete detail of a legal graph community, specifying the included content (articles, internal relations, external connections). This gives a specific purpose, though it does not explicitly differentiate from sibling tools like 'legal_graph' or 'law_articles'.
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. The description does not mention any conditions, prerequisites, or alternative tools, leaving the agent without direction on selecting 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states that it calculates deadlines in business days, but omits details like holiday handling, input/output format, or any side effects. The behavior is largely opaque.
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 communicates the core purpose without wasted words. It is easy to parse and appropriately sized for a simple calculation tool, earning its place with clear content.
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 lack of annotations and output schema, and the presence of five parameters, the description is insufficient for an agent to correctly invoke the tool. It omits parameter roles, return format, and assumptions about business days/holidays, making it incomplete in 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?
Schema description coverage is 0%, and the description does not explain any of the five parameters. It doesn't mention the required fecha_recepcion parameter's role or the meaning of the optional date fields. The description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Calcula' and clearly identifies the resource 'plazos ARCO' and the scope 'en días hábiles'. This distinguishes the tool from sibling tools like process_case or validate_case, 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 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. There is no mention of context, prerequisites, or exclusions. The description implies it is for calculating ARCO deadlines but offers no comparative guidance with sibling tools.
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 only states the detection purpose and does not mention whether the operation is read-only, what inputs it expects, what outputs it produces, or any side effects. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no wasted words. It is front-loaded with the action and enumerates the key objects. While it is concise, it is somewhat minimal given the tool's complexity, but that is more a completeness issue than a conciseness flaw.
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?
The tool has no annotations, no output schema, and only one parameter that is completely undocumented. The description fails to explain the input format (case_json), the nature of the output, or any context about what 'ARCO' channels are. For a tool with such limited schema info, the description is far from 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 one parameter (case_json) with no description coverage (0%). The tool description does not mention the parameter at all, leaving the agent without any guidance on what case_json should contain or how it relates to the identity risk detection. The description fails to compensate for the schema's lack of information.
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 'Detecta' (detects) and clearly specifies the resource: risks related to incorrect business name, trade name, branch, or unofficial ARCO channel. This distinguishes it from sibling audit tools like audit_argumentation and source_audit, which focus on different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (when identity-related risks need to be checked) but does not explicitly state when to use this tool versus alternatives or provide any exclusions. There is no mention of alternative tools or conditions, so guidance is only implicit.
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. It describes the audit scope but does not mention whether the tool is read-only, what it returns, or any prerequisites or side effects, leaving significant 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 enumerates the audited aspects. 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?
Given the tool has no annotations and no output schema, the description is too brief to provide complete context. It lacks information about input expectations, return values, or when to use this specific audit tool over its many siblings.
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 a single parameter case_json with no description, and schema coverage is 0%. The tool description does not explain what case_json should contain, its format, or any constraints, providing no added meaning beyond the name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool audits provenance, official source, freshness of privacy notice, and risk of using third parties as legal basis. This specific verb and resource listing distinguishes it from sibling audit tools like audit_argumentation and audit_identity.
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 source/provenance audit is needed) but does not explicitly explain when to use it versus alternatives or provide exclusions. With several audit siblings, more explicit guidance would be helpful.
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 carries the full burden. It only discloses a precondition (validation passing) but does not describe whether the tool modifies any state, what input format is expected, or what the output draft looks like. This is insufficient for a drafting action.
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 fluff. It effectively front-loads the purpose and condition. However, the brevity may be at the expense of necessary detail.
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 one parameter, no annotations, and no output schema, the description should explain what happens after validation, what the draft contains, and any limitations. It only provides a gate condition, leaving the tool's overall behavior underspecified relative to its siblings.
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 0% description coverage, and the description does not mention 'case_json' at all beyond referring to 'el caso'. It does not explain the expected structure, required fields, or how the case data is used in drafting.
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 drafts an ARCO request (Redacta una solicitud ARCO), providing a specific verb and resource. It also distinguishes from sibling tools like validate_case or assess_case by focusing on drafting, and adds a condition that narrows its applicability.
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 'solo si el caso supera la validacion critica' explicitly tells the agent when this tool should be used, implying a validation step must precede it. While it doesn't name the exact sibling tool to call first, it provides a clear gate condition.
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. It discloses neither the return format nor whether the tool is read-only or has side effects. The input-format warning is useful but is not a description of the tool's behavior or outcomes.
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 and followed by a critical input instruction. Every sentence has purpose, and the all-caps warning is salient without being verbose.
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?
With no output schema and no annotations, the description should explain what the audit returns or at least mention the optional case_json parameter. It does neither, leaving an incomplete picture for an agent deciding whether this tool covers the needed functionality.
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 only 50%; the optional case_json parameter is not described in the schema nor in the description. The description reinforces draft_text's plain-text requirement, but the undocumented case_json remains a gap that hurts parameter understanding.
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 names a specific verb ('audita') and a specific resource ('un borrador ARCO'), and enumerates the concrete audit targets (wrong authority, misused articles, imprecise sanction threats). This clearly distinguishes it from other audit siblings like audit_identity or source_audit, which focus on different aspects.
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 does not state when to use this tool versus the many sibling audit tools. It does give an important input-format guideline (pass plain text, not JSON), which helps invocation but not tool selection or alternative comparison.
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. It discloses that it runs a multi-stage pipeline and emphasizes the input must be JSON, not text, but does not mention side effects, return format, or prerequisites. This is thin for a complex pipeline tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the tool's role and input constraint. 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?
Despite being a pipeline with multiple stages, the description does not explain what the tool returns or outputs, and there is no output schema. It also omits any context about prerequisites beyond JSON format. This makes it incomplete for an agent invoking the tool.
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 already covers the single parameter with a description (must start with '{'). The description adds the clarification 'NO texto' (not text), reinforcing that case_json must be structured JSON, which is a modest enhancement over the schema. Baseline 3 is appropriate.
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 it is a complete pipeline to validate, substantiate, argue, and draft, using specific verbs tied to the case resource. It also says 'Use first,' which partially distinguishes it as the entry point, though it does not explicitly contrast with sibling tools like validate_case.
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 instruction 'Usar primero' (use first) provides clear guidance that this is the intended starting tool. However, it does not mention when to avoid it or suggest alternative tools for specific steps, so it lacks exclusions or alternatives.
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?
Since no annotations are provided, the description carries the full burden. It discloses the core behavior (assessment and output categories) but does not mention whether the operation is read-only, has side effects, requires authentication, or has limitations. For a potentially complex legal analysis tool, more behavioral context 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 exceptionally concise, front-loaded with the main purpose, and uses a single sentence to convey both the action and the outcome categories. Every word 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description adequately conveys the purpose and expected outcome categories. However, it does not explicitly describe the return format or provide details on how the prognosis/implications are structured. Given the simplicity, this is a minor gap, but the description is suff
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 description covers 100% of the parameter ('JSON del caso'), so the description does not need to add much. It merely restates that the tool receives case_json without adding structure or format details, aligning with the baseline score.
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: to assess legal solidity (irrefutable/solid/weak/unsustainable) and provide legal implications and prognosis. It specifies the input (case_json) and distinguishes itself from sibling tools like process_case and validate_case by focusing on outcome classification rather than processing or validation.
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 simply says 'Recibe case_json' without any mention of prerequisites, exclusions, or comparison to sibling tools, leaving the agent without direction on appropriate selection.
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 must carry the full burden of behavioral disclosure. It states the tool 'returns' legal basis, implying a read operation, but it does not explicitly declare side effects, permissions, or return format. The dependency on 'etapa' is mentioned, but other behavioral traits remain unexplained.
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, clear sentence that front-loads the action and object. It includes all necessary information without verbosity, effectively serving its 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?
Given the tool's simplicity (one enum parameter, no output schema), the description provides adequate context about the content domain (legal bases for escalation). However, it lacks explanation of the parameter values and the structure of the returned legal basis, leaving some ambiguity for the 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?
The description references 'según la etapa' which connects the parameter to the behavior, but it does not explain the meaning of the enum values ('escalamiento_secretaria' and 'amparo') or how they affect the output. With 0% schema description coverage, the description fails to compensate for the 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's function: it returns a complete legal basis for the escalation phase, listing specific laws (LFPDPPP, LFPA, Ley de Amparo, Constitución). The phrase 'según la etapa' indicates variability based on stage, distinguishing it from sibling tools that likely handle different granularity or 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 description explicitly scopes the tool to the escalation phase ('para fase de escalamiento'), giving clear context for when to use it. It does not mention alternatives or conditions for when not to use it, but the context is sufficient for an agent to infer appropriate 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes what is audited but says nothing about return format, side effects, permissions, or whether the tool is read-only. This leaves agents uncertain about what to expect after invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first lists specific flaws to audit, the second clarifies the tool's relationship to audit_draft. 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with no output schema, the description should at least hint at what the tool returns (e.g., a report of flaws). It does not, though the purpose and scope are clear enough for basic selection and invocation.
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% ('Texto del borrador.') and the tool description restates 'borradores' without adding extra meaning. Since the schema already documents the parameter, the baseline of 3 applies.
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 'Audita' (audits) and the resource 'vicios argumentativos en borradores' (argumentative flaws in drafts), listing specific flaw types. It explicitly distinguishes itself from audit_draft, 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?
The description mentions 'Complementa a audit_draft' and explains audit_draft reviews legal correctness, which implies when to use this tool for argumentative flaws. However, it does not explicitly state exclusions or other alternatives beyond audit_draft, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It discloses that the tool returns all relationships and includes article IDs, implying a read-only query. But it does not mention output format specifics, potential performance characteristics, or error conditions, leaving some behavioral aspects opaque.
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 exactly two sentences, front-loaded with the core purpose and scope. Each clause adds information (what it is, what it returns, and how it relates to law_articles), with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and no output schema, the description gives a reasonable overview but leaves the output structure undefined. It states the types of relationships returned and that article IDs are included, but not the JSON shape, which is needed for reliable integration when no output schema exists.
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 0% description coverage, so the description must compensate. It says 'Dado uno o mas articulos' (given one or more articles), which conveys the parameter's purpose, but it does not explicitly state that article_numbers_json expects a JSON-encoded array string. The parameter name partially fills that gap, but the description adds only plain-language meaning.
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 a semantic relationship graph between legal articles, enumerates relationship types (requires, limits, overrides, complements), and emphasizes it returns ALL such relationships. It also mentions linking to law_articles for further queries, distinguishing its purpose from simpler article lookup tools.
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 you need to discover legal relationships between articles, and references law_articles as a follow-up tool. However, it does not explicitly compare against siblings like semantic_search or argument_map, nor does it state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description is the sole source. It indicates a read-only retrieval behavior via 'Devuelve', but doesn't disclose any additional behavioral traits such as auth requirements, side effects, or limitations. It's adequate 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with the first being a metaphorical statement of limited informational value. The second sentence is efficient and front-loads the core functionality and usage directive. Overall sized well.
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?
Given the tool has a single parameter and no output schema, the description covers the function and usage. However, it omits details about the input format and any assumptions about the case, which could be critical for correct invocation. The mention of counter-articles and full articles gives some output expectations.
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 one parameter 'case_json' with no description, so schema coverage is 0%. The description references 'el caso' implying the input is the case data, but it doesn't explain the expected format or structure. This partially compensates but leaves ambiguity.
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 evasion tactics applicable to the case, with exact counter-articles and full articles. The verb 'Devuelve' and specific resources distinguish it from sibling analysis tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs to use this tool BEFORE drafting the 'DESESTIMACION DE DEFENSAS PREVISIBLES' section, providing clear temporal guidance. It does not mention alternatives or when not to use it, but the context is strong.
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?
There are no annotations, so the description carries the burden. It indicates a search operation and states the output type (communities and articles), implying a read-only behavior. Yet it does not explicitly state side-effect-free execution, nor any limits or prerequisites, so it is moderately transparent.
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 with no filler; the first sentence names the tool's scope and the second provides the usage pattern and expected output. Every word contributes.
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 one-parameter search tool with no output schema, the description states the input and the high-level output (communities and specific articles). It also flags the global scope. It could add more details about result ordering or limitations, but it is adequate for initial tool selection.
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 input schema only provides a 'query' string with default and no description coverage. The description compensates by explaining that the parameter is a natural-language question, adding key semantic meaning beyond the raw schema. However, it does not elaborate on format, language, or example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Busqueda semantica global sobre el grafo juridico', clearly stating a search action over the legal graph. It further specifies what it returns (relevant communities and articles), distinguishing it from sibling tools like community_detail or law_articles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains the tool is for natural-language questions ('Dada una pregunta en lenguaje natural'), giving a clear use context. However, it does not explicitly mention when not to use it or name alternatives, so it stops at clear context but no exclusions.
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 are present, so the description carries the burden. It discloses the validation purpose and input constraints but doesn't specify return format, side effects, or any additional behavioral traits. It implies a read-only audit but doesn't state it explicitly.
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: the first states the purpose, the second provides critical input instructions. It is front-loaded and every sentence adds value.
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?
With no output schema and no annotations, the description should explain the return value or result format, but it doesn't. It thoroughly covers input and purpose, but the missing output behavior is a gap for a complete understanding. For a single-param tool, it's mostly complete but lacks return details.
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 case_json is fully described in the schema with format and example. The description adds the specific required fields (titular, responsable, datos_personales, derechos_solicitados), which goes beyond the schema's example and clarifies the expected content.
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 validates whether an ARCO case is ready to be drafted without critical legal gaps, using the specific verb 'Audita' and identifying the resource (caso ARCO). It distinguishes from sibling tools like audit_draft by focusing on case readiness rather than draft text.
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 input requirements: it expects case_json (a JSON string with specific fields) and explicitly warns not to pass draft text, which differentiates it from audit_draft. However, it doesn't explicitly mention alternative tools or when not to use it beyond the draft text exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool performs a verification (read-only operation) and specifies the information returned. It does not mention side effects or permissions, but for a health check this is adequate. It adds value by describing the return payload and the recommended usage timing, though it could be more explicit about non-destructiveness.
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 extremely concise: three short sentences in Spanish. The first sentence states the core purpose, the second lists the key return elements, and the third gives usage timing. Every sentence earns its place, and the structure is front-loaded with the main action.
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 health-check tool with no parameters and no output schema, the description is complete. It clearly states what the tool does, what it returns, and when to use it. There is no missing information needed for an agent to decide when and how to invoke it correctly, and no complexity requires further elaboration.
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 empty. According to the baseline for 0 params, a score of 4 is appropriate. The description does not need to explain parameters since there are none, and the description's focus on the tool's purpose and return values is sufficient.
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: 'Verifica que el MCP este operativo' (verifies that the MCP is operational). It specifies the verb 'verify' and the resource 'MCP', and distinguishes it from sibling tools, which are all case-processing actions, by focusing on server health.
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?
Explicit usage guidance is provided: 'Usala al inicio de cada sesion' (use it at the beginning of each session). This tells the agent when to invoke the tool, and the description of returned data (version, articles, graph nodes, communities) implies it is for checking system state, distinguishing it from sibling tools that process cases.
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:

[![arco-rights-mcp MCP server](https://glama.ai/mcp/servers/isaacwars/arco-rights-mcp/badges/card.svg)](https://glama.ai/mcp/servers/isaacwars/arco-rights-mcp)

Score Badge

Copy to your README.md:

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

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