How do I use MCP Server Python?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Server Python buscar jurisprudência sobre dano moral no STJ" 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.

MCP Server Python

by KandellOliveira

Overview Schema Related Servers Score Discussions

Python

Remote

Servidor MCP em Python

Projeto base de um servidor MCP (Model Context Protocol) em Python, pronto para conectar em clientes MCP.

Requisitos

Python 3.10+

Related MCP server: simple-mcp

Instalar

python3 -m venv .venv
source .venv/bin/activate
pip install -e .

Executar

mcp-server-python

Ou usando o utilitario solicitado:

mcpserver

O servidor sobe em modo stdio, que e o formato mais comum para integrar com clientes MCP locais.

Configurar cliente MCP

VS Code

Copie examples/vscode.mcp.example.json para .vscode/mcp.json.
Se necessario, ajuste command para o Python da sua venv.
Reinicie o cliente MCP no VS Code.

Exemplo:

{
	"servers": {
		"python-mcp-server": {
			"type": "stdio",
			"command": "${workspaceFolder}/.venv/bin/python",
			"args": ["-m", "mcp_server"]
		}
	}
}

Claude Desktop

Abra o arquivo de configuracao do Claude Desktop.
Copie o conteudo de examples/claude_desktop_config.example.json.
Troque /CAMINHO/ABSOLUTO/PARA/... pelo caminho real do projeto.

Exemplo:

{
	"mcpServers": {
		"python-mcp-server": {
			"command": "/CAMINHO/ABSOLUTO/PARA/mcp_server/.venv/bin/python",
			"args": ["-m", "mcp_server"]
		}
	}
}

Tools disponiveis

ping() -> str
soma(a: float, b: float) -> float
agora() -> str
inverter_lista(itens: list[str]) -> list[str]
buscar_jurisprudencia(consulta: str, tribunal: str | None = None, limite: int = 10) -> dict
detalhe_jurisprudencia(url_ou_urn: str) -> dict
buscar_jurisprudencia_avancada(consulta: str, tribunal: str | None = None, orgao: str | None = None, data_inicio: str | None = None, data_fim: str | None = None, limite: int = 5) -> dict

Jurisprudencia com dados abertos

O servidor inclui um modulo para consulta de jurisprudencia em fonte aberta via LexML Brasil.

Fluxo recomendado

Use buscar_jurisprudencia com termos como icms creditamento, dano moral consumidor, prisao preventiva.
Pegue a url ou urn de um resultado.
Use detalhe_jurisprudencia para obter metadados e ementa.

Exemplos de parametros:

buscar_jurisprudencia(consulta="icms energia", tribunal="stj", limite=5)
detalhe_jurisprudencia(url_ou_urn="urn:lex:br:superior.tribunal.justica;turma.1:acordao;resp:2006-03-09;601056-676848")

Busca avancada para analise

Use buscar_jurisprudencia_avancada quando quiser:

recorte por periodo (data_inicio e data_fim)
filtro de orgao (turma, secao, pleno, camara, carf)
retorno com resumo_prompt pronto para colar em um modelo e pedir analise comparativa

Exemplo:

buscar_jurisprudencia_avancada(consulta="icms creditamento energia", tribunal="stj", orgao="turma", data_inicio="2015-01-01", data_fim="2024-12-31", limite=3)

Estrutura

src/mcp_server/server.py: definicao do servidor e tools.
src/mcp_server/legal_open_data.py: integracao com dados juridicos abertos.
src/mcp_server/__main__.py: ponto de entrada para execucao.
pyproject.toml: metadados, dependencias e script CLI.

Available Tools

7 tools

agoraA

Retorna data e hora atuais no formato ISO 8601.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior3/5

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

No annotations provided. Description discloses the output format but does not elaborate on potential side effects, authorization needs, or system dependencies. Acceptable for a simple read-only 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?

Single sentence, front-loaded with key information. No extraneous content.

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 zero parameters and output schema present, the description fully covers what the tool does. No gaps.

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?

No parameters to describe. Schema coverage is 100% (empty). Baseline for 0 params is 4, and description adds no parameter details, which is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it returns current date and time in ISO 8601 format. Uses specific verb and resource. No sibling tools perform similar functions, so no confusion.

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?

No explicit guidance on when or when not to use, but the tool is straightforward with no parameters and no overlapping siblings. Implicit usage is clear.

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

buscar_jurisprudenciaC

Busca jurisprudencia em dados juridicos abertos (LexML).

ParametersJSON Schema

Name	Required	Description	Default
`limite`	No
`consulta`	Yes
`tribunal`	No

TDQS

C2.7/5.0

Behavior2/5

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

With no annotations, the description carries full burden but only states the tool searches data. It does not disclose behavioral traits such as read-only nature, rate limits, pagination, or error handling. Minimal value added beyond the name.

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, concise and to the point. It avoids verbosity but could benefit from a brief parameter overview or usage hints.

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 absence of output schema and parameter descriptions, the description is incomplete. It does not explain return format, default behavior, or how to filter results, which are necessary for effective tool use.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. However, it provides no explanation of the three parameters (consulta, limite, tribunal), leaving the agent without semantic context for proper invocation.

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 searches jurisprudence in open legal data (LexML) using the verb 'busca' and the resource 'jurisprudencia'. It is unambiguous but does not explicitly distinguish from sibling tools like buscar_jurisprudencia_avancada.

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 prerequisites, scenarios, or exclusions.

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

buscar_jurisprudencia_avancadaC

Busca avancada de jurisprudencia com filtros e resumo para analise.

ParametersJSON Schema

Name	Required	Description	Default
`orgao`	No
`limite`	No
`consulta`	Yes
`data_fim`	No
`tribunal`	No
`data_inicio`	No

TDQS

C2.4/5.0

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 mentions 'resumo para analise' (summary for analysis) but does not detail return format, pagination, rate limits, or whether the tool modifies data. It fails to disclose important behavioral traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single short sentence. While concise, it lacks structure such as a breakdown of parameter usage or use cases. It is not overly verbose but could be more informative.

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 6 parameters, no output schema, and no annotations, the description is highly incomplete. It fails to explain how filters work, what the summary contains, or the relationship to sibling tools. The tool is complex, and the description does not provide adequate context for effective use.

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%, yet the description does not explain any of the 6 parameters (e.g., 'orgao', 'tribunal', 'data_inicio'). It only generically mentions 'filtros' without linking to specific parameters. This leaves the agent unable to understand how to use the inputs.

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 performs an advanced search of jurisprudence with filters and summary. It distinguishes from related tools by using 'avancada' (advanced), but does not explicitly contrast with the sibling 'buscar_jurisprudencia'.

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 advanced search versus the basic search or other tools. The description does not mention any prerequisites, exclusions, or scenario-specific advice.

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

detalhe_jurisprudenciaC

Retorna metadados e ementa de um item de jurisprudencia.

ParametersJSON Schema

Name	Required	Description	Default
`url_ou_urn`	Yes

TDQS

C2.8/5.0

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 burden of behavioral disclosure. It only states what is returned, not that the operation is read-only or has no side effects. Minimal transparency beyond the 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, clear sentence that gets straight to the point. However, it is slightly too terse, omitting parameter details that could be included without harming conciseness.

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?

For a simple tool with one parameter and no output schema, the description is incomplete. It fails to specify the parameter format, return structure, or usage context, making it insufficient for an agent to reliably 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 'url_ou_urn' has no schema description (0% coverage) and the tool description does not explain its format, expected values, or constraints. The agent lacks necessary information to correctly provide the parameter.

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?

Description clearly states it retrieves metadata and summary (ementa) of a jurisprudential item, using the specific verb 'Retorna'. The name 'detalhe_jurisprudencia' distinguishes it from sibling search tools like 'buscar_jurisprudencia' and 'buscar_jurisprudencia_avancada'.

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?

Description provides no guidance on when to use this tool versus alternatives. It does not mention that it is for retrieving details of a specific item, whereas siblings are for searching. No explicit when-to-use or when-not-to-use information.

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

inverter_listaA

Retorna uma nova lista com os itens em ordem inversa.

ParametersJSON Schema

Name	Required	Description	Default
`itens`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

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

The description states it returns a new list, implying immutability, but does not disclose other behavioral traits such as handling of empty arrays, error conditions, or performance implications. Since no annotations are provided, the description carries the full burden but only partially addresses it.

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 immediately conveys the core functionality. It has no redundancy and maintains front-loaded structure.

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 simplicity of the tool (one parameter, straightforward operation), the description is nearly complete. It could mention edge cases like an empty array, but the presence of an output schema reduces the need for return value 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?

With 0% schema description coverage, the description adds meaning by explaining the effect of the 'itens' parameter: the tool returns them in reverse order. This clarifies the parameter's role beyond the schema's type definition.

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 new list with items in reverse order, using a specific verb ('retorna') and resource ('lista'). It distinguishes from sibling tools that perform unrelated operations like ping, sum, or jurisprudence queries.

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?

No explicit guidance is provided on when to use this tool versus alternatives. The usage is implied by the simple nature of the tool, but the description lacks when-not-to-use or alternative suggestions.

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

pingB

Retorna um status simples para validar se o servidor esta funcionando.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

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 does not disclose if the tool is read-only, safe, or what the response structure is. The description is minimal and fails to add value beyond the name.

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, concise and to the point. However, it is front-loaded but very sparse.

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?

Despite having an output schema, the description does not mention the response format. For a trivial tool it may be acceptable, but additional context like 'returns { status: string }' would improve completeness.

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?

There are no parameters, so baseline is 4. The description adds no parameter information, but none is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns a simple status to validate if the server is working. The verb 'returns' and resource 'status' are specific, and the purpose is distinct from siblings which are likely computation or 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 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 vs alternatives. For a basic ping, it could be implied for connectivity checks, but explicit context is missing.

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

somaA

Soma dois numeros.

ParametersJSON Schema

Name	Required	Description	Default
`a`	Yes
`b`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior3/5

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

No annotations were provided, so the description carries full burden. It states the operation (addition) but does not disclose edge cases, return type, or behavior for non-number inputs. For a simple arithmetic tool, this is minimally acceptable.

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 extremely concise (3 words). While it is efficient, it could be slightly more informative without sacrificing brevity. The front-loading is fine: the purpose is stated immediately.

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 (adding two numbers), the description is nearly complete. However, it does not explain the return value or handle edge cases like large numbers. The presence of an output schema partially compensates, but it is not shown here.

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

Parameters2/5

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

Schema description coverage is 0%, and the description does not add any meaning beyond the parameter names (a and b). It fails to describe what each parameter represents or any constraints. Baseline should be higher due to low coverage, but description provides no compensation.

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 'Soma dois numeros' (Adds two numbers) clearly states the verb and resource. It is specific and distinguishes the tool from sibling tools like ping or buscar_jurisprudencia, 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 Guidelines3/5

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

No explicit guidance on when to use or alternatives. However, the tool's purpose is straightforward (summing numbers), so usage is implied. No exclusions or when-not-to-use advice is provided.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

7 tool updatesv0.1.0Jul 28, 2026
- First observedagora
- First observedbuscar_jurisprudencia
- First observedbuscar_jurisprudencia_avancada
- First observeddetalhe_jurisprudencia
- First observedinverter_lista
- First observedping
- First observedsoma

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: ping is a health check, soma does arithmetic, agora provides date/time, inverter_lista reverses lists, and the three jurisprudencia tools handle different aspects of legal document search (basic, detail, advanced). No two tools overlap in functionality.

Naming Consistency3/5

Names are in Portuguese but follow mixed patterns: some are single nouns (ping, soma, agora), some are verb_noun (inverter_lista, buscar_jurisprudencia), and one is noun_noun (detalhe_jurisprudencia). The advanced search includes an adjective suffix. This inconsistency can confuse an agent trying to infer naming conventions.

Tool Count3/5

With 7 tools, the count is moderate. However, the tools cover two unrelated domains (generic utilities and legal research), making the set feel like a collection of random functions rather than a focused server. The number is not extreme but the lack of thematic cohesion reduces appropriateness.

Completeness2/5

The legal research subset has basic search, detail retrieval, and advanced search, but lacks any write operations (e.g., save, annotate). The generic utilities are a few arbitrary functions (ping, sum, date, reverse list) with no broader context or coverage of a domain. The surface feels incomplete and arbitrary.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

smithery-ai-cookbook-python-quickstart
ai.smithery
A simple MCP server built with FastMCP and python
Developer Tools
213
mcp A
ai.llmse
Public MCP server for the LLM Search Engine
Search RAG Systems Developer Tools
102
Dados Abertos Senado BR MCP A
io.github.SidneyBissoli
MCP server for Brazilian Federal Senate open data (legislative, administrative, e-Cidadania).
Government Data Open Data
6925
Second server!
com.fenetresurciel.verylongmcp
A non functional MCP server (yet)
Developer Tools
2

Related MCP Servers

Minimal MCP
Developer Tools Education & Learning Tools
engineers-hub-ltd-in-house-project
F
license
Not graded
quality
D
maintenance
A basic educational MCP server that provides simple tools for mathematical calculations, text manipulation, and time retrieval. Designed for learning MCP implementation patterns and development purposes.
Updated a year ago (2025-08-24 02:28 UTC)
-
simple-mcp
Developer Tools
hareramray
F
license
Not graded
quality
C
maintenance
A minimal MCP server providing basic tools for arithmetic, text echoing, and timezone-aware current time retrieval.
Updated 3 months ago (2026-06-20 17:44 UTC)
-
Developer Toolbox MCP
Developer Tools File Systems Command Line
Apoorva5544
F
license
Not graded
quality
C
maintenance
A production-ready MCP server providing file, system, math, and text utilities through a simple CLI client.
Updated 2 months ago (2026-06-28 08:13 UTC)
-
mcp-utility-server
Developer Tools Browser Automation
Chengyue2025
F
license
Not graded
quality
B
maintenance
A Python-based MCP server providing essential utility tools: web fetching, current time, and calculator functionality.
Updated a month ago (2026-07-30 03:08 UTC)
-

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/KandellOliveira/mcp_server'

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