Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@condosplit calcola suddivisione bolletta luce gen-feb 2026 €150,52"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Plugin MCP per Claude Code — suddivisione automatica delle spese condominiali.
condosplit è un MCP server che estende Claude Code con strumenti dedicati alla gestione e ripartizione delle spese condominiali. Una volta installato, basta chiedere a Claude in linguaggio naturale e lui calcola le quote, mostra lo schema dell'edificio e mantiene lo storico.
git clone https://github.com/sntfrancesco/condosplit.git condosplit
cd condosplit
npm installIl server va installato una volta sola a livello globale: legge condo.config.json dalla directory corrente, quindi funziona in qualsiasi progetto senza ulteriori configurazioni.
claude mcp add -s user condosplit node /percorso/assoluto/condosplit/src/server.jsOppure modifica manualmente ~/.claude/settings.json:
{
"mcpServers": {
"condosplit": {
"command": "node",
"args": ["/percorso/assoluto/condosplit/src/server.js"]
}
}
}claude mcp listRelated MCP server: SplitwiseMCP
Dopo l'installazione, Claude dispone di questi strumenti che può chiamare autonomamente durante la conversazione.
Inizializza un progetto condosplit nella directory correnteCrea condo.config.json e una copia di README_GUIDE-condosplit.md nella directory di lavoro.
Mostrami lo schema del condominioCalcola la suddivisione della bolletta luce di gen-feb 2026 per €150,52
Dividi la pulizia scala di febbraio 2026 da €80,00
Ripartisci la quota ascensore del primo trimestre 2026 di €210,50 e salvala nello storicoQuando vengono calcolate spese e sono presenti coordinate di pagamento configurate, Claude mostrerà la lista e chiederà quale includere nel report.
Mostrami le coordinate di pagamento disponibili
Aggiungi una coordinata: Enel Energia, IBAN IT60X0542811101000000123456, banca Intesa SanpaoloLe coordinate vengono salvate in condo.coordinates.json nella directory del progetto. Ogni tipo di spesa in condo.config.json può avere un campo defaultPaymentCoordinatesId che suggerisce la coordinata predefinita.
Mostrami lo storico delle spese condominialiStrumento | Descrizione |
| Crea |
| Visualizza lo schema ASCII dell'edificio |
| Elenca i tipi di spesa configurati |
| Calcola la suddivisione di una spesa; se sono presenti coordinate, chiede quale includere nel report |
| Mostra lo storico delle spese salvate |
| Elenca le coordinate di pagamento in |
| Aggiunge o aggiorna una coordinata di pagamento |
condo.coordinates.jsonFile generato automaticamente nella directory di progetto. Contiene tutte le coordinate di pagamento configurate. Viene creato vuoto da condosplit_init e popolato con condosplit_coordinates_save.
{
"coordinates": [
{
"id": "enel_energia",
"label": "Enel Energia",
"intestatario": "Condominio Via Roma 1",
"iban": "IT60X0542811101000000123456",
"swift": "BCITITMM",
"banca": "Intesa Sanpaolo",
"causale": "Bolletta luce scala",
"note": "Inserire numero cliente in causale"
}
]
}Tutti i campi tranne id e label sono opzionali.
condo.config.json{
"building": {
"name": "Nome condominio",
"floors": [
{
"level": 1, // numero piano
"label": "Primo Piano", // etichetta leggibile
"staircaseAccess": true, // false = nessun accesso scala (es. piano terra negozi)
"units": [
{ "id": "I1.a", "label": "Proprietario A" },
{ "id": "I1.b", "label": "Proprietario B", "occupied": false } // non abitato
]
}
]
},
"expenseTypes": [
{
"id": "pulizia_scala", // usato nel tool condosplit_split
"name": "Pulizia Scala",
"splitRule": "occupied_staircase_equal", // solo abitati con accesso scala
"defaultPaymentCoordinatesId": "impresa_pulizie" // ID in condo.coordinates.json (opzionale)
},
{
"id": "bolletta_luce",
"name": "Bolletta Luce Scala",
"splitRule": "utility_breakdown",
"utilityComponents": [
{ "name": "Autoclave", "percentage": 33, "splitGroup": "all" },
{ "name": "Ascensore", "percentage": 34, "splitGroup": "occupied_staircase" },
{ "name": "Luce Scala", "percentage": 33, "splitGroup": "occupied_staircase" }
]
}
]
}occupied per unitàOgni unità accetta il campo opzionale "occupied": false per indicare che l'interno è non abitato.
Il default è true (abitato): omettere il campo equivale a "occupied": true.
Nello schema dell'edificio le unità non abitate sono marcate con ⊘.
splitRule)Valore | Comportamento |
| Quota uguale tra tutte le unità |
| Quota uguale tra unità con |
| Quota uguale tra unità abitate |
| Quota uguale tra unità abitate con |
| Ripartizione per componenti, ognuno con percentuale e gruppo |
splitGroup) — per utility_breakdownValore | Unità incluse |
| Tutte le unità |
| Unità con |
| Unità abitate |
| Unità abitate con |
condosplit/
├── src/
│ ├── server.js ← entry point MCP server
│ ├── config.js ← caricamento e validazione configurazione
│ ├── building.js ← rendering schema ASCII
│ ├── expenses.js ← logica di ripartizione
│ ├── report.js ← formattazione report
│ ├── history.js ← storico spese
│ ├── coordinates.js ← gestione coordinate di pagamento
│ └── init.js ← inizializzazione progetto
├── examples/
│ ├── condo.config.json
│ └── condo.coordinates.json
├── package.json
├── README.md
└── README_GUIDE-condosplit.mdNode.js >= 18
Claude Code con supporto MCP
MIT
Elenca tutte le coordinate di pagamento salvate in condo.coordinates.json (IBAN, banca, intestatario, ecc.).
| Name | Required | Description | Default |
|---|---|---|---|
| config_path | No | Percorso al file condo.config.json. Default: ./condo.config.json |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. 'Elenca' implies a read-only operation and the description identifies the source file and data categories, but it does not disclose behavior on missing files, invalid config paths, or whether config_path influences which coordinates file is read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It states the action, the file, and the content examples efficiently, every part earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description provides enough context to invoke it correctly. The only notable gap is the implicit connection between config_path and the coordinates file, but the default path and clear examples keep this from being a major blocker.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents the only parameter, config_path, including its default. The tool description adds no meaning about why or how config_path relates to condo.coordinates.json, so it stays at the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Elenca' (lists) and names the exact resource: payment coordinates saved in condo.coordinates.json, with concrete field examples (IBAN, banca, intestatario). This clearly distinguishes it from its sibling condosplit_coordinates_save, which implies a write operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the list-oriented wording and by the sibling coordinate_save tool, but the description does not explicitly state when to choose this tool over alternatives or what conditions call for it. It gives no exclusions, just an implicit read/list purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Aggiunge o aggiorna una coordinata di pagamento in condo.coordinates.json. Se l'ID esiste già, sovrascrive il record.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Identificatore univoco della coordinata (es. "enel_energia", "impresa_pulizie"). | |
| iban | No | Codice IBAN. | |
| note | No | Note aggiuntive (es. "includere numero cliente in causale"). | |
| banca | No | Nome della banca. | |
| label | Yes | Nome leggibile della coordinata (es. "Enel Energia", "Impresa Pulizie Rossi"). | |
| swift | No | Codice SWIFT/BIC (opzionale, utile per bonifici internazionali). | |
| causale | No | Causale standard predefinita per questa coordinata (verrà usata se non specificato diversamente). | |
| config_path | No | Percorso al file condo.config.json. Default: ./condo.config.json | |
| intestatario | No | Intestatario del conto/beneficiario del pagamento. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It usefully reveals that the operation is an upsert and that an existing record is overwritten ('Se l'ID esiste già, sovrascrive il record'). However, it does not clarify whether omitted optional fields are cleared or preserved during an update, nor what the tool returns or how it reports errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise, front-loaded sentences. The first states the core action, and the second adds the most important behavioral caveat. There is no filler or redundant repetition of parameter names.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with nine parameters and no output schema or annotation, the description is somewhat thin. It correctly identifies the target file and the overwrite behavior, which is essential context, but it omits guidance on partial updates, return values, and failure handling. These gaps are significant but not crippling because the schema covers parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all nine parameters. The description adds no additional semantic detail beyond naming the target file and emphasizing the uniqueness of the id field. Baseline 3 is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Aggiunge o aggiorna') and a concrete resource ('una coordinata di pagamento in condo.coordinates.json'). It is unambiguous about the tool's purpose, but it does not explicitly contrast itself with sibling tools like condosplit_coordinates, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells the agent what the tool does, but provides no guidance on when to choose it over alternatives. There is no mention of prerequisites, when a read-only sibling would be more appropriate, or when this save operation should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mostra lo storico delle spese salvate con il flag save=true.
| Name | Required | Description | Default |
|---|---|---|---|
| config_path | No | Percorso al file condo.config.json. Default: ./condo.config.json |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does convey a read-only behavior through 'Mostra' and a filtering condition through 'save=true', but it does not describe output format, error behavior, or any reliance on config_path state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant wording. Every part contributes meaning, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description gives enough context about the core behavior and filtering condition. It does not explain the returned structure, but the low complexity and clear purpose make the description largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the single optional config_path parameter is already fully documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, which matches the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows the history of expenses saved with the save=true flag, using a specific verb and resource. It does not explicitly distinguish itself from sibling tools, but no sibling covers the same history functionality, so the purpose is sufficiently clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, nor does it mention any exclusions or prerequisites. Usage must be inferred entirely from the stated purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inizializza un progetto condominiale: crea condo.config.json con la struttura di default (4 piani + piano terra, 2 interni per piano, 3 tipi di spesa predefiniti) nella directory specificata.
| Name | Required | Description | Default |
|---|---|---|---|
| project_dir | No | Percorso assoluto o relativo della directory di progetto. Default: directory corrente. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It explicitly states that the tool creates a file and details the default structure, which is good. However, it does not mention whether it overwrites an existing condo.config.json, what happens if the directory is invalid, or whether it returns any confirmation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that wastes no words. It front-loads the action and resource, then packs the essential default configuration details into one clause, all without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 is largely complete: it explains what is created, where it is created, and what the default contents are. It could be slightly more complete by stating behavior on existing files, but for a simple init operation the essential context is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes project_dir as the absolute or relative path with a default of the current directory, so schema coverage is 100%. The description's phrase 'nella directory specificata' merely echoes the schema without adding new semantics or format details. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Inizializza'), a clear resource ('progetto condominiale'), and the concrete output it produces ('crea condo.config.json con la struttura di default'). It also specifies the default structure (4 piani + piano terra, 2 interni per piano, 3 tipi di spesa predefiniti), which clearly differentiates this tool from siblings like condosplit_split or condosplit_coordinates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly conveys when to use the tool: when initializing a condominium project and creating the default configuration file in a target directory. It does not explicitly list alternatives or exclusions, but the verb 'Inizializza' and the mention of creating the config file provide enough context to distinguish it from the other condosplit tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Visualizza lo schema grafico ASCII dell'edificio condominiale con piani, interni ed etichette. Mostra quali unità hanno accesso alla scala.
| Name | Required | Description | Default |
|---|---|---|---|
| config_path | No | Percorso al file condo.config.json. Default: ./condo.config.json |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states this is a 'Visualizza' operation, implying a read-only action, and discloses what the user will see: an ASCII schema, floors, interiors, labels, and stair access. However, with no annotations, it does not detail potential errors, file requirements, or any side effects; for a visualization tool this is mostly adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, focused sentences with no filler. The main function is stated immediately, and the second sentence adds a useful detail about stair access without bloating the definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple visualization tool with one optional parameter, the description covers the core action and expected output content despite lacking an output schema. It does not explain when to choose this tool over siblings, but the simplicity and self-contained nature keep it reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single optional parameter, including its default value. The description itself does not mention config_path, but since the schema already documents it thoroughly, the description adds no extra semantic burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: displaying an ASCII graphic schema of the condominium building with floors, interiors, and labels, and highlighting which units have stair access. It uses a specific verb ('Visualizza') and resource, though it does not explicitly differentiate from sibling tools by name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like condosplit_coordinates, condosplit_split, or condosplit_types. The context implies a visualization/inspection role, but there is no explicit usage condition or rationale.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calcola la suddivisione di una spesa condominiale tra gli interni e restituisce il riepilogo dettagliato con la quota di ciascun interno. Se payment_coordinates_id non è specificato e sono presenti coordinate salvate, restituisce anche la lista delle coordinate disponibili così che l'utente possa scegliere quale includere nel report.
| Name | Required | Description | Default |
|---|---|---|---|
| save | No | Se true, salva la spesa nello storico (condosplit-history.json). Default: false. | |
| label | Yes | Etichetta descrittiva della spesa (es. "Bolletta luce gen-feb 2026"). | |
| amount | Yes | Importo totale della spesa. Accetta virgola o punto come separatore decimale (es. "150,52" o "150.52"). | |
| config_path | No | Percorso al file condo.config.json. Default: ./condo.config.json | |
| expense_type_id | Yes | ID del tipo di spesa come definito in condo.config.json (es. "bolletta_luce", "pulizia_scala", "ascensore"). | |
| payment_coordinates_id | No | ID della coordinata di pagamento (da condo.coordinates.json) da includere nel report. Se omesso e sono disponibili coordinate salvate, il tool restituisce la lista per consentire la scelta. |
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 does reveal the conditional behavior of returning available coordinates when payment_coordinates_id is omitted, and frames the operation as compute-and-return. However, it does not mention potential persistence through 'save' or any side effects, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences. The first states the main function and output; the second adds the important conditional behavior. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose, the output summary, and the conditional coordinate-selection workflow. Since there is no output schema, some detail about the exact response structure is absent, but the description is sufficient for a moderately complex tool with well-documented parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 adds a bit of contextual meaning for payment_coordinates_id, but that behavior is already documented in the parameter's own description. No significant semantic value is added beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Calcola') and resource ('suddivisione di una spesa condominiale tra gli interni'), and states the output: a detailed summary with each unit's share. It is clearly distinguished from sibling tools about coordinates, history, and initialization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The core use case is clear from the first sentence. It also gives actionable guidance: if payment_coordinates_id is not specified and saved coordinates exist, the tool returns the list so the user can choose which to include. It does not explicitly state when not to use it, but the context is not misleading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Elenca tutti i tipi di spesa configurati in condo.config.json con le relative regole e criteri di ripartizione.
| Name | Required | Description | Default |
|---|---|---|---|
| config_path | No | Percorso al file condo.config.json. Default: ./condo.config.json |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden, and it clearly frames the operation as read-only ('Elenca') and scopes the result to expense types, rules, and criteria from a named config file. It does not mention error behavior if the config file is missing, but the read-only nature is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-formed Italian sentence with no filler. It front-loads the action and immediately states the resource and what is included in the result.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, optional-parameter list tool, the description sufficiently communicates the input (config file, default covered by schema) and output content. It lacks explicit output shape and error handling, but no output schema exists and the description already names the returned entities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the only parameter config_path already has a clear description and default value. The tool description adds no additional parameter semantics, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Elenca') and resource ('tutti i tipi di spesa configurati in condo.config.json') and clarifies the output includes rules and allocation criteria. This cleanly differentiates it from siblings like condosplit_split, condosplit_init, and condosplit_schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: call this when you need the configured expense types and their splitting rules. However, there is no explicit when-to-use/when-not-to-use guidance or mention of alternatives such as condosplit_schema or condosplit_history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0condosplit_coordinatescondosplit_coordinates_savecondosplit_historycondosplit_initcondosplit_schemacondosplit_splitcondosplit_typesOgni tool ha uno scopo chiaramente distinto: inizializzare, visualizzare lo schema, elencare i tipi di spesa, calcolare la ripartizione, gestire le coordinate e leggere lo storico. Anche i due tool sulle coordinate si distinguono bene perché uno salva/aggiorna e l'altro elenca.
Tutti i tool condividono il prefisso condosplit_ e usano snake_case, ma la struttura interna è mista: alcuni nomi sono solo sostantivi (schema, types, history), altri sono verbi (init, split), e uno usa ordine sostantivo-verbo (coordinates_save). La convenzione è leggibile ma non uniforme.
Sette tool sono una dimensione adeguata per il dominio di gestione delle spese condominiali: coprono inizializzazione, visualizzazione, calcolo e storico senza risultare superflui o sovrabbondanti.
Il flusso principale è coperto: init, split, storico e gestione coordinate sono presenti. Mancano però operazioni importanti come creare/modificare i tipi di spesa, eliminare coordinate o modificare la struttura dell'edificio dopo l'inizializzazione, rendendo il set non completamente autonomo.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
MCP server giving Claude AI access to 22+ NYC public-record databases for real estate due diligence
The Ramp MCP server enables users to securely connect Ramp with AI assistants like ChatGPT and Claude to query financial data and take actions using natural language. It transforms Ramp's developer API into a SQL interface that LLMs can query, allowing admins to analyze spend trends, identify cost savings, and run complex SQL analyses on comprehensive datasets (transactions, purchase orders, vendors, users), while all users can manage cards, view transactions, request reimbursements, and get expense policy answers.
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/sntfrancesco/condosplit'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
