bogamatic-sac-mcp

by inncode-io

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.1
Disambiguation4/5
Most tools have clearly distinct purposes, but there is some overlap between get_detalle_cedula and get_resumen_cedula, with the latter explicitly combining the former with calcular_plazo. This could cause misselection, though descriptions help. Similarly, get_operaciones_expediente and get_texto_operacion_expediente are complementary but distinct.
Naming Consistency5/5
All tool names follow a consistent snake_case verb_noun pattern, with 'get_' for retrieval, 'download_', 'calcular_', and 'send_' for actions. The singular/plural use (cedula/cedulas, expediente/expedientes) is logical and predictable. No mixed naming conventions are present.
Tool Count5/5
With 12 tools, the server is well-scoped for its domain of legal case management and notifications. Each tool addresses a specific need, and the count is within the ideal range for a focused MCP server. No redundant or unnecessary tools are apparent.
Completeness4/5
The tool surface covers the primary workflows: listing and reading cedulas, searching and viewing expedientes, retrieving operations and attachments, downloading files, calculating deadlines, and sending notifications. Minor gaps exist, such as lacking a way to filter attachments by operation or explicitly marking a cedula as seen, but these are workable or handled automatically.
Average 4.3/5 across 12 of 12 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 18 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 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?
With no annotations provided, the description carries the full burden. It discloses that textoOperacion is 'converted to Markdown' and lists all return fields including nested adjuntos. It does not mention error behavior or authorization, but for a simple get operation it provides substantial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the purpose, followed by a compact list of return fields. Every element is informative and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter, no output schema, and no annotations, the description is nearly complete. It fully specifies the return contract including field names and formatting. It lacks only peripheral details like error conditions or required permissions, which are not critical for a simple getter.
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 already has full coverage (100%) with a clear description for idCedula, including a cross-reference to get_novedades_cedulas. The tool description itself adds no parameter details, so baseline 3 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 uses a specific verb and resource: 'Get the full detail of a specific cedula notification.' It also enumerates the exact return fields, clearly distinguishing this from siblings like get_resumen_cedula and get_novedades_cedulas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'full detail' implies it is for complete information, contrasting with get_resumen_cedula, and the parameter description references get_novedades_cedulas as a source. However, there is no explicit statement of when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the 7-day activity filter and the return fields, which is useful. However, it doesn't mention pagination behavior, ordering, or that it returns only summary data. The 'Get' verb implies read-only, but safety traits are not explicitly stated.
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, direct sentence stating the operation, the time filter, and the return fields. There is no redundancy or filler, making it efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple paginated list tool with high-coverage schema and an output schema, the description covers the essential purpose and returns. It doesn't explicitly note that it returns only a summary or specify ordering, but the current text is sufficient for an agent to correctly invoke 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 input schema has 100% description coverage for both pageSize and pageIndex, so the schema already documents the parameters. The tool description adds no parameter-specific information, only the return fields. This meets the baseline for high 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 uses the specific verb 'Get' and identifies the exact resource: 'expedientes (cases) that had activity in the last 7 days'. It lists return fields (case number, title, court, status, location), distinguishing it from sibling tools like get_novedades_cedulas and get_expediente. This makes the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The temporal filter 'in the last 7 days' provides clear context for when this tool is appropriate. It doesn't explicitly mention alternatives or exclusions (e.g., use get_expediente for full case details), but the 'novedades' (updates) use case is clearly distinct from the other sibling tools.
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 burden of behavioral disclosure. It explains the return shape, including date format, idOperacion prefix pass-through guidance, and the flattened extras dict. It is clearly a read operation ('Get'), and the additional detail about how to handle IDs adds useful context beyond a basic read hint.
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 dense sentence that front-loads the main purpose and then lists return fields. It is efficient with no filler, though the list format could be slightly better structured. Overall it earns its length by conveying essential return semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema covers parameters and an output schema exists, the description adequately explains the tool's return contract and even provides cross-tool pass-through guidance. It lacks an explicit 'when not to use' statement, but for a simple, well-annotated schema it is sufficiently complete.
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 100% with descriptions for both idExpediente and includeEspeciales. The tool description does not add parameter-specific meaning beyond the schema, but it does clarify what the returned 'operations' include, which indirectly aids interpretation. With high schema coverage, baseline 3 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 exact action and resource: 'Get all operations (movements) for a specific expediente.' It distinguishes from sibling tools like get_novedades_expedientes (novelties) and get_texto_operacion_expediente (single operation text) by focusing on the full list of operations. This is specific and non-tautological.
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 fetching operations/movements, and the schema's parameter description for idExpediente tells the agent where to obtain the expediente ID (from get_novedades_expedientes or get_expedientes). It does not explicitly cite alternatives or exclusions, but the context is clear enough for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It explains that the recipient is auto-resolved from the authenticated user's account and that cedula details are loaded server-side, adding useful context beyond the schema. However, it does not describe output or failure modes.
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 primary action, and every sentence provides relevant context. No redundant or excessive 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?
For a one-parameter send tool with an output schema, the description covers the purpose, recipient resolution, and data loading. It lacks explicit when-to-use guidance, but overall it is sufficient for an agent to select and invoke the tool 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?
Schema coverage is 100% for the single parameter, and the description adds further meaning by stating that idCedula is the same ID used by get_resumen_cedula, linking it to sibling tools and clarifying how it is used.
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 'Send a WhatsApp notification about a cedula' with a specific verb and resource. This distinguishes it from the sibling get_* tools, which are all read-only operations.
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 by requiring an idCedula and referencing get_resumen_cedula, but it does not explicitly state when to use this tool versus alternatives or when not to use it. No exclusions or alternative recommendations are provided.
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?
While no annotations are present, the description discloses the return structure, including the E:/O: prefix pass-through behavior and the date format, and frames the operation as a read-only 'Get.' It does not explicitly mention auth, pagination, or side effects, but for a simple list operation it provides meaningful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two logically structured sentences: first states the purpose and return fields, second gives actionable downstream usage. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single parameter, a provided output schema, and a clear description covering purpose, return fields, and interaction with download_adjunto, the description is complete for agent use. The output schema covers return values, so no further detail is needed.
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, idExpediente, is already fully described in the schema with 'Expediente ID' (100% schema coverage). The description does not add extra meaning about the parameter's format or constraints, so baseline 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 uses the specific verb 'Get' with a clear resource ('all attachments for an expediente') and enumerates the returned fields, distinguishing it from sibling tools like download_adjunto, which is referenced as the follow-up operation.
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 context (listing attachments for an expediente) and explicitly instructs to pass idFichero, idOperacion, and nombre to download_adjunto, creating a clear usage workflow. It does not discuss when not to use this tool vs other siblings, but the workflow guidance is sufficient.
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 carries the full burden. It adds useful behavioral details like returning Markdown and preserving the E:/O: prefix, but omits side effects, error behavior, and authorization requirements. This is minimally adequate.
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 front-loads the purpose and immediately follows with the parameter usage instruction. No wasted 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 one-parameter getter with no annotations and an output schema, the description is sufficiently complete. It covers what the tool does, the format of output, and exactly how to obtain and pass the required ID.
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 100% for the single parameter, establishing a baseline of 3. The description adds value beyond the schema by naming the exact source tools and emphasizing the need to preserve the prefix, making it more helpful than a bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'text content of an operation within an expediente', and the output format 'Markdown'. It distinguishes itself from siblings by explaining that the ID comes from get_operaciones_expediente or get_adjuntos_expediente.
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 instructs to pass the idOperacion exactly as returned by get_operaciones_expediente or get_adjuntos_expediente, providing a clear prerequisite and source for the parameter. It does not mention exclusions or alternative tools, but the context is sufficient for proper 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 behavior beyond the schema: it clarifies that results are scoped to the authenticated lawyer, that 'caratula' supports fuzzy matching with partial names, and that 'numeroExpediente' uniquely identifies an expediente. With no annotations, this is valuable behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, beginning with the core action, then a search nuance, then a guidance note. Every sentence adds information without redundancy.
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, combined with the fully-described schema and output schema, provides a sufficient understanding of the tool's scope, auth constraints, search behavior, and filter priority. It could mention pagination behavior but that is inferable from the schema defaults.
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?
Although the schema covers all six parameters with descriptions, the description enhances semantics by specifying fuzzy search behavior for 'caratula' and the uniqueness/preference for 'numeroExpediente.' This goes beyond the nominal parameter descriptions.
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 'Search' and identifies the resource 'legal expedientes (cases/files)' with the scope 'belonging to the authenticated lawyer.' It distinguishes from siblings by noting the list/plural nature and the fuzzy search capability.
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 guidance to prefer 'numeroExpediente' as the primary filter when a case number is provided, which is a clear usage instruction. It does not explicitly reference alternative tools, but the context implies this is the listing/search tool while siblings handle details or notifications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It clearly states that fetched cedulas are stored and that New/SEEN status depends on prior fetches, implying a state-changing side effect beyond a simple read.
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 front-loaded purpose. Every sentence contributes meaning, with zero redundancy.
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 list tool with pagination and sorting parameters, the description adequately explains the core behavior and side effects. It lacks explicit return structure, but no output schema exists, and the description conveys the essential output concept (list of cedulas with NEW/SEEN status).
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%, so the baseline is 3. The description does not add parameter-specific meaning beyond the schema; pagination and sorting are self-explanatory.
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 'Get the list of electronic cedula notifications', specifying the verb, resource, and scope. It distinguishes itself from siblings like get_novedades_expedientes by focusing on cedulas.
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 that this tool retrieves cedula novedades, which is distinct from the expediente-focused sibling tools. However, it does not explicitly mention when not to use it or name alternative tools.
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 transparency burden. It discloses the counting logic (3 business days, skipping weekends and court holidays) and explicitly states the output (the date when the deadline period begins). This exceeds basic expectations, though it could mention edge-case behavior for invalid dates.
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, three sentences long, and front-loaded with the primary action. Every sentence contributes: what it does, the legal rule, and the return value—no superfluous information.
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 no output schema, the description is complete. It covers the legal basis, calculation rule, and return value, and given the sibling context, it is clear when to use this 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?
Schema coverage is 100%, so the schema already documents the format. The description adds meaning by framing the parameter as a 'notification date' and explaining its legal significance, which helps the agent understand what to pass and why.
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 calculates the first day a procedural deadline begins, given a notification date. It specifies jurisdictional context (Cordoba, Argentina) and the exact rule (3 business days forward, skipping weekends and court holidays), distinguishing it from sibling getter 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 provides clear context: use when you have a notification date (typically from a cedula) and need to know when the deadline period starts. It does not explicitly name alternatives or exclusions, but the sibling tools are all read operations, making the use case evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing the destination resolution order (MCP client root, SAC_DOWNLOAD_DIR env var, ~/Downloads/bogamatic-sac/) and the exact filename pattern. It does not mention potential overwrite behavior or error cases, but the disclosed details are meaningful and go beyond the name and schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct (about 60 words) and front-loaded: the first sentence states the core purpose, followed by scope, destination selection, and naming. Each sentence contributes necessary information without 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?
Given the tool's moderate complexity, the description fully covers what it does, which types of attachments it handles, how the local destination is determined, and how files are named. An output schema exists, so not describing the return value is acceptable. The description is complete enough 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage with clear descriptions for each parameter. The description adds extra value by explaining that numeroExpediente and fechaOperacion are used in the local filename construction, and by noting that idOperacion is 'prefixed, as returned by parent tools' which reinforces the schema's own note. This goes beyond merely restating 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 starts with a specific verb+resource: 'Download an attachment locally.' It also explicitly states that it works for both cedulas (via get_detalle_cedula adjuntos[]) and expediente operations (via get_adjuntos_expediente), which clearly differentiates it from sibling read-only getter 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 provides clear context on when to use: after obtaining attachments from either of the two named parent tools. However, it does not explicitly state when not to use it or mention any alternative download tools, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full transparency burden. It discloses that the response includes a `partes` block, `ladoUsuario`, `esUsuario`, and a fallback where `partes` is null with an error reason. It also implies authentication context via the user's matrícula. It doesn't mention behavior for 'not found' but covers key state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence is information-dense and earns its place: action, usage timing, return structure, field semantics, fallback behavior, and downstream guidance. There is no redundant fluff, and the main verb is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully explains the return shape and behavioral nuances (partes block, ladoUsuario, esUsuario, partesError). It also places the tool in the larger workflow by linking to sibling tools. This is sufficient for an agent to invoke it and interpret results.
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 already describes both parameters (100% coverage), but the description adds the crucial relationship: either numeroExpediente OR idExpediente is used, and idExpediente is the internal ID to be passed to downstream tools. This adds meaning beyond the schema's individual field descriptions.
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 ('Look up'), the resource ('a single expediente'), and the key identifiers ('numeroExpediente OR idExpediente'). It distinguishes itself from the sibling tool get_expedientes by implying singular vs. plural use.
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?
Explicitly says 'Use this at the start of any chat about a case' and directs the agent to use the returned idExpediente with subsequent tools (get_operaciones_expediente, get_adjuntos_expediente). It doesn't explicitly list exclusions, but the context clearly implies when it is appropriate.
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?
There are no annotations, so the description carries the full burden. It clearly discloses what the tool returns (detailed field list) and that it combines two operations. While it doesn't mention side effects or permission requirements, it's a read-only summary operation and the description gives sufficient behavioral context for an 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 concise and well-structured: a one-sentence purpose, a bullet-like list of returned fields, and an explicit usage tip. Every sentence contributes value, with no redundancy or 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?
Given the tool has only one parameter and no output schema, the description provides a complete picture: it fully enumerates the return fields and explains how it relates to sibling tools. It covers the necessary context for an agent to invoke it 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 already provides a descriptive parameter explanation ('The cedula ID (field 'idCedulaDestinatario' from get_novedades_cedulas)') with 100% coverage. The tool description adds no extra parameter meaning beyond the schema, so the baseline score of 3 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 starts with a specific verb and resource: 'Get a complete summary of a cedula in a single call.' It clearly distinguishes itself from siblings by explicitly stating it combines get_detalle_cedula + calcular_plazo, which are two separate sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Use this instead of calling get_detalle_cedula and calcular_plazo separately.' This provides clear guidance over alternatives, making it a strong usage guideline.
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:

[![bogamatic-mcp MCP server](https://glama.ai/mcp/servers/inncode-io/bogamatic-mcp/badges/card.svg)](https://glama.ai/mcp/servers/inncode-io/bogamatic-mcp)

Score Badge

Copy to your README.md:

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

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